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Abstract 


This  thesis  is  concerned  with  the  organization  and  structure  of 
dialogue  between  an  interactive  information  system  and  its  users. 


In  particular,  the 

thesis 

proposes 

an 

extension 

to 

TAXIS  (see 

[Mylopoulos  et  al 

78a, 

78b,  and 

79] 

and  [ Wong 

80]) 

to  provide 

facilities  for  the  design  of  such  dialogues.  Dialogue  structure  is 
accomplished  in  terms  of  augmented  Petri  nets  while  dialogue 
organization  is  accomplished  in  terms  of  the  TAXIS  framework  of 
properties,  classes,  and  the  IS-A  hierarchy.  Two  long  examples 
involving  an  airline  ticket  acquisition  system  and  a  journal  editing 
system  are  also  given  to  illustrate  the  features  of  the  proposed 


extension  to  TAXIS 
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Introd  uc  tion 


1-.1  Motivation 

We  are  concerned  with  the  design  of  TAXIS,  a  programming 
language  for  interactive  information  systems  Jabnrev.  IISs).  These 
systems  are  characterized  by  large  volumes  of  short,  interactive, 
and  highly  predictable  transactions  on  a  database.  Examples  of  such 
applications  include  systems  for  credit  card  verification,  airline 
and  hotel  reservations,  student-course  registration,  and  inventory 
control.  The  motivation  outlined  in  this  section  is  based  on  that 
presented  in  [ Mylopoulos  et  al  78a,  78b,  and  79]. 

One  may  ask  why  design  yet  another  programming  language.  Our 
response  is  that  the  high  cost  of  software  development  of  IIS 
applications,  which  are  distinguished  from  other  applications  by 
large  amounts  of  conceptually  simple  detail,  is  partly  due  to  the 
inadeguate  programming  facilities  offered  in  such  conventional 
languages  as  COBOL  and  PL/1.  T AXIS  provides  extra  mechanisms,  not 
found  in  these  conventional  languages,  for  the  organization  of  this 
detail  in  an  intellectually  simpler  and  easier  manner. 

Until  recently,  applications  programming  was  usually  carried 
out  by  using  a  data  sublanguage  embedded  in  a  conventional 
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applications  programming  language.  A  more  recent  trend,  exemplified 
by  TAXIS,  is  to  design  an  applications  programming  language  that  has 
among  other  things,  database  management  facilities.  That  is,  TAXIS 
combines  constructs  for  describing  a  database  and  the  transactions 
that  operate  on  it,  the  exceptions  that  could  arise  during  the 
operation  of  the  IIS,  and  the  exception  handling  procedures  that 
should  be  followed  when  they  do  arise. 

Cheaper  hardware  costs  have  made  it  economical  to  implement 
more  and  more  IIS  applications.  Yet,  in  spite  of  the  apparent 
conceptual  simplicity  that  these  systems  exhibit,  software  costs  are 
quite  high.  Little  work  has  been  done  in  developing  a  methodology 
for  IIS  design.  Current  research  in  database  management  is  centered 
around  such  topics  as  generalized  retrieval  algorithms,  concurrency 
control,  semantic  integrity  schemes,  and  sophis tica ted  query 
languages.  Solutions  to  these  problems,  although  important,  will 
have  little  effect  on  IIS  design  per  se .  The  type  of  research 
effort  exemplified  by  TAXIS,  on  the  other  hand,  centers  around  the 
development  of  new  abstraction  mechanisms  for  IIS  programming  which 
provide  a  natural  way  for  organizing  the  large  amounts  of  detail 
that  are  inherent  in  IIS  applications.  The  primary  abstraction 
mechanism  studied  in  TAXIS  is  based  on  the  IS- A  relationship 
[Quillian  68]  and  facilitates  a  new  design  methodology  for  IISs 
which  we  have  called  stepwise  refinement  through  specialization 
[Wong  80].  This  is  in  sharp  contrast  to  stepwise  refinement  through 
decomposition  [Wirth  71]  which  is  the  dominant  program  design 
principle  in  use  now. 
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We  believe  that  TAXIS  can  have  an  impact  on  applications 
programming  for  systems  that  are  conceptually  simple  but  involve 
large  amounts  of  detail.  It  is  our  hope  that  software  costs  for  the 
design,  implementation,  and  maintenance  of  such  systems  will  be 
significantly  reduced  through  the  use  of  new  design  tools  such  as 
those  proposed  by  TAXIS. 

JL  2  Overview 

Previous  work  by  [Mylopoulos  78a,  78b,  79]  and  [Wong  80]  has 
resulted  in  the  design  of  a  language  that  allows  the  description  of 
the  data  structures  and  transactions  constituting  the  heart  of  an 
IIS.  No  facilities  are  provided,  however,  for  the  description  of 
user  interfaces,  even  though,  as  pointed  out  in  [Carlson  and  Metz 
79],  the  description  of  user  interfaces  is  the  most  expensive  part 
of  an  IIS  design.  This  thesis  is  concerned  with  the  design  of  user 
interfaces  for  TAXIS  programs.  More  specifically,  it  deals  with  the 
problems  of  describing  the  types  of  dialogue  through  which  a  user 
can  interact  with  an  IIS  and  the  organizational  structure  of  this 
interface . 

TAXIS  tools  proposed  in  this  thesis  only  allow  the 
specification  of  the  pragmatic  component  of  an  IIS,  just  as  TAXIS 
itself  offers  tools  for  the  specification  of  the  semantic  component. 
Another  extension  of  TAXIS  is  currently  being  investigated  which 
will  allow  the  specification  of  a  linguistic  component  for  an  IIS, 
i.e.  the  specif ication  of  the  allowable  syntactic  forms  for 


messages  exchanged  between  an  IIS  and  its  users. 
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The  pragmatic  component  of  TAXIS  serves  as  the  control 
mechanism  for  initializing,  conducting,  and  terminating  dialogues 
between  an  IIS  and  its  users.  That  is,  it  manages  calls  to  a  TAXIS 
parser  to  translate  user  linguistic  inputs  into  TAXIS  expressions, 
evaluates  these  expressions  with  respect  to  the  semantic  component, 
and  returns  the  results.  It  also  provides  the  context  under  which 
dialogues  take  place.  A  user  can  only  perform  dialogue  acts 
expected  by  the  IIS  given  the  previously  completed  dialogue.  Thus, 
the  pragmatic  component  of  TAXIS  provides  the  organization  and 
structure  for  user/IIS  dialogues  by  serving  as  the  interface  between 
the  linguistic  and  semantic  components  of  TAXIS. 

1. 3  Results 

This  thesis  contains  two  new  results.  First,  we  successfully 
extend  TAXIS,  within  the  existing  TAXIS  framework  of  classes, 
properties,  and  the  IS-A  relationship,  to  include  two  new 
metaclasses,  called  scripts  and  transitions  respectively.  Script 
classes  are  modelled  using  a  modified  version  of  Zisman*s  APN 
(Augmented  Petri  Net)  representation  [  Zisman  "77  and  78]  while 
transition  classes  provide  the  details  of  each  transition  in  an  APN. 
An  important  feature  of  scripts  is  their  ability  to  run  concurrently 
with  facilities  for  inter-script  communication  ana  coordination. 
Second,  we  demonstrate  the  suitability  of  scripts  for  modelling  two 
IIS  applications:  an  airline  ticket  acquisition  system  and  a 
journal  editing  system.  In  particular,  we  show  that  we  have  a 
sufficient  range  of  dialogue  facilities  to  model  the  required 
dialogues  for  these  applications.  We  also  present  evidence  that  our 
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APN  formalism  is  suitable  for  structuring  dialogues  exhibited  by 
other  systems  with  goals  similar  to  TAXIS. 

1.  4  Background 

The  design  of  script  and  transition  metaclasses  has  beer 
influenced  to  a  large  extent  by  previous  work.  This  section  gives  a 
brief  review  of  that  work.  More  detailed  descriptions  can  be  found 
in  the  remaining  chapters  of  the  thesis. 

As  mentioned  before  (see  [Mylopoulos  et  al  78a,  78b,  and  79] 
and  [Wong  BO]),  the  basic  concepts  in  TAXIS  are  those  of  class, 
property,  and  the  IS-A  relationship  between  classes.  The  semantic 
component  of  TAXIS  uses  these  concepts  to  provide  a  framework  that 
offers  database  management  facilities,  a  means  of  specifying 
integrity  constraints,  exception  handling,  and  organizational 
principles  for  TAXIS  programs.  A  brief  introduction  to  this 
component  of  TAXIS  can  be  found  in  Appendix  A. 

Hoare  [  Hoare  ’78]  has  proposed  some  novel  input/output  commands 
for  communication  between  sequential  processes.  Corresponding  pairs 
of  these  commands  can  be  used  to  pass  data  internally  between 
concurrently  running  processes  and/or  to  coordinate  the  execution  of 
these  processes. 

Zisman's  doctoral  dissertation  [  Zisman  77  ]  is  concerned  with 
the  modelling  of  office  procedures,  which  can  be  described  as  a 
collection  of  asynchronous  concurrent  processes.  To  accomplish 
this,  he  proposes  a  formalism,  called  an  augmented  Petri  net  (APN) , 
which  uses  Petri  nets  to  provide  a  control  mechanism  for  production 
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systems.  A  brief  introduction  to  Petri  nets  is  given  in  Appendix  E. 
1 . 5  Outline 

Chapter  2  presents  the  first  IIS  example:  an  airline  ticket 

acquisition  system.  The  APN  formalism  for  modelling  scripts  along 
with  script  and  transition  classes  are  introduced  in  this  chapter. 
A  dialogue  example  using  the  airline  ticket  acquisition  script 
demonstrates  how  primitive  dialogue  commands  are  used  to  pass 
messages  between  users  and  the  IIS.  Finally,  the  original  script  is 
refined  using  stepwise  refinement  through  specialization  to  apply  to 
a  charter  airline  ticket  acquisition  system. 


Chapter  3  presents  the  syntax  and  informal  semantics  of  TAXIS 
script  and  transition  classes.  The  inter-script  communication  and 
dialogue  commands  and  predicates  are  explained  and  illustrated  with 
numerous  examples.  The  program  design  methodology,  as  given  in 
[Kong  80],  is  extended  to  include  scripts.  The  IS-A  constraints 
governing  the  allowable  specializations  of  script  (and,  as  a  result, 
cf  transition)  classes  are  outlined. 


Chapter  4  presents  the  second  IIS  example:  a  journal  editing 
system.  This  example  demonstrates  the  power  of  the  inter-script 
communication  commands  and  predicates  both  for  passing  information 
between  concurrently  running  editor  and  referee  script  instances  and 
for  coordinating  these  script  instances  at  various  points  in  their 
execution.  The  dialogue  example  given  in  this  chapter  shows  how  the 
journal  editing  system  can  conduct  dialogues  with  many  users  at  the 


same 


The  exception  handling  mechanism  for  scripts  is 


time . 
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illustrated  in  this  IIS  example. 

Chapter  5  is  essentially  a  detailed  survey  of  various  work  with 
goals  and  features  common  to  TAXIS.  The  capabilities  of  two  office 
systems,  SCOOP  and  OFS,  are  compared  to  those  of  TAXIS.  The 

features  and  philosophies  of  two  office  systems  programming 
languages,  OPSL  and  BDL,  are  discussed  with  respect  to  TAXIS.  The 

dialogue  capabilities  of  three  natural  languages  front  ends, 

RENDEZVOUS,  PLANES,  and  LIFER,  are  examined.  Finally  evidence  that 
TAXIS  can  support  at  least  as  sophisticated  dialogues  as  any  of 
these  front  ends  is  presented. 

Lastly,  Chapter  6  provides  concluding  remarks  and  discusses 
areas  of  future  research. 

Appendix  A  presents  a  brief  introduction  to  the  semantic 
component  of  TAXIS.  The  reader  may  wish  to  read  this  if  he  has  no 
background  in  TAXIS.  Appendix  B  presents  a  short  description  of 


Petri  nets. 
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An  Airline  Ticket  Acquisition  System 


2. 1  Introduction  to  Scripts 

As  mentioned  in  Chapter  1,  the  concept  of  scripts  is  used  to 
organize  and  structure  dialogue  flow  in  IIS  applications.  A  script 
is  a  preset  known  plan  to  accomplish  some  goal.  Thus  a  script  sets 
up  expectations  about  events  likely  to  follow  in  a  given  situation. 
TAXIS  scripts  would  be  designed  for  different  well  defined 
situations.  As  such,  a  script  is  a  linked  set  of  states  that  can 
branch  into  multiple  possible  paths  that  may  eventually  come 
together  at  some  points  of  the  script.  The  decision  of  what 
particular  path  to  follow  is  determined  by  the  user  input  (i.e. 
dialogue  acts)  and  the  current  state  of  the  system  and  so  scripts 
are  both  event  and  data-driven. 

An  important  feature  of  TAXIS  scripts  is  the  ability  of 
concurrently  running  script  instances  to  have  either  time  dependent 
or  time  independent  coordination  within  or  between  them.  Thus  TAXIS 
scripts  require  a  mechanism  for  modelling  both  synchronous  and 
asynchronous  concurrent  processes.  Modified  forms  of  Zisman*s 
[Zisman  77  and  78]  augmented  Petri  nets  and  Hoare*s  [Hoare  78]  I/O 
commands  for  communicating  sequential  processes  are  adopted  as  tools 
for  modelling  synchronous  and  asynchronous  concurrent  processes. 
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2i2  Script  Representa tion 

TAXIS  scripts  are  modelled  using  augmented  Petri  nets  (abbrev. 
APNs)  .  An  APN  is  built  using  a  Petri  net  with  a  condi tion -act ion 
pair  associated  with  each  of  its  transitions.  A  brief  introduction 
to  Petri  nets  is  given  in  Appendix  B.  Petri  nets  are  used  to  model 
the  temporal  relationships  between  events  and  condition-action  pairs 
to  model  the  knowledge  associated  with  individual  events.  Only  when 
all  the  conditions  associated  with  an  enabled  transition  ace  true 
and  the  actions  of  the  condition-action  pair  have  been  successfully 
carried  out  will  that  transition  fire.  If  more  than  one  transition 
can  fire,  then  the  order  of  firing  in  nondeterministic.  All  the 
conditions  at  all  enabled  transitions  constitute  what  is  known  as 
the  active  transition  set.  The  enabling  and  firing  of  transitions 
will,  of  course,  change  membership  in  this  set.  The  enabling  and 
firing  of  transitions  represents  the  occurrence  of  events  and,  as 
such,  various  dialogue  acts  may  be  needed  to  carry  out  these  events. 
These  dialogue  acts  will  be  actions  in  the  condition-action  pairs. 

The  APN  formalism  adopted  here  is  a  simplified  form  of  Zisman's 
APN  formalism  [  Zisman  77  and  78].  Instead  of  using  condi tion -action 
pairs  Zisman  associates  whole  production  systems  with  each  Petri  net 
transition.  Only  when  one  production  rule  in  the  production  system 
associated  with  an  enabled  transition  has  a  true  condition  will  the 
associated  actions  for  that  rule  be  executed  and  the  transition 
fired.  All  production  rules  of  all  production  systems  at  all 
enabled  transitions  constitute  what  Zisman  calls  the  active  rule 
set.  Membership  in  the  active  rule  set  changes  by  the  enabling  and 


AN  AIRLINE  TICKET  ACQUISITION  SYSTEM 


Page  10 


CHAPTER  2 

firing  of  transitions.  If  we  viewed  each  condition-action  pair  of 
TAXIS  scripts  as  a  production  system  with  only  one  rule  we  have 
something  like  Zisman's  formalism.  However,  several  other 
differences  exist.  The  production  rules  of  Zisman's  formalism  have 
access  to  a  STM  (Short  Term  Memory)  for  state  data.  Scripts,  on  the 
other  hand,  do  not  use  STMs  but  rather  acguire  state  data  by 
examining  their  local  variables  (or  the  local  variables  of  other 
scripts)  and  accessing  information  from  the  database.  Scripts  can 
also  share  data  with  other  concurrently  running  scripts  using  I/O 
commands  and  predicates  (see  next  chapter).  Zisman's  APNs  halt 
execution  when  no  rules  in  the  active  rule  set  are  true  or  the 
action  of  an  executing  rule  is  the  special  action  stop;  scripts 
halt  only  when  the  active  transition  set  is  empty  or  an  explicit 
termination  command  has  been  executed.  That  is,  a  script  will  check 
and  recheck  all  conditions  in  the  active  transition  set  in  a  cyclic 
manner  even  if  none  of  them  are  presently  true.  (They  may  later 
become  true  as  a  result  of  some  physical  event,  dialogue  act,  or 
communication  with  another  concurrently  running  script)  . 

2.1.3  A  Script  Example  for  Acquiring  an  Airline  Ticket 

TAXIS  scripts  are  modelled  using  APNs.  As  an  example  of  the 
power  of  the  APN  representation  for  organizating  and  structuring 
dialogue  flow  consider  a  simple  airline  reservation  system  and  the 
kind  of  dialogue  it  should  support.  Details  about  a  TAXIS 
representation  of  the  data  and  transaction  classes  that  are  relevant 
to  this  system  are  given  informally  in  Appendix  A. 
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The  acquisition  of  an  airline  ticket  involves  two  steps: 
making  a  reservation  and  purchasing  a  ticket.  To  make  a  reservation 
the  script  must  obtain  information  about  the  flight  (the  date  and 
flight  number)  and  the  passenger  (his  name,  address,  and  telephone 
number).  If  the  flight  date  is  invalid  (i. e.  it  is  within  one  day 
of  the  current  date)  it  is  rejected  and  another  date  sought.  Once 
this  information  has  been  correctly  obtained,  the  system  proceeds  to 
make  the  reservation  and  then  expects  payment.  If  full  payment  is 
made  at  this  time  a  ticket  is  immediately  issued.  If  partial 
payment  is  made  then,  unless  the  balance  is  paid  within  one  hour  of 
flight  time,  the  reservation  is  automatically  cancelled  and  any 
payment  made  refunded.  Of  course,  if  the  balance  is  paid  on  time,  a 
ticket  is  issued.  If  no  payment  is  made  at  all  between  the  time  the 
reservation  was  made  up  to  one  day  before  the  flight,  the 
reservation  is  again  automatically  cancelled.  Three  different 
payment  methods  are  permitted:  cash,  cheque,  and  credit  card. 
Thus,  it  is  possible  to  pay  for  a  ticket  by  making  many  partial 
payments  using  different  payment  methods  at  different  times.  Also 
the  passenger  can  cancel  his  reservation  at  any  time  after  it  has 
been  made  right  up  until  the  flight  time  and  receive  a  refund  if 
partial  payments  have  been  made  or  a  ticket  has  been  issued.  If  a 
refund  is  required  for  any  reason  the  refund  method  will  depend  on 
the  payment  method  (s)  used. 

An  instance  of  the  script  for  acquiring  an  airline  ticket  using 
the  above  algorithm  may  run  for  an  undetermined  period  of  time.  For 
example,  a  passenger  can  make  a  reservation  a  month  or  so  in  advance 
and  then  make  payments  of  varying  amounts  during  the  month  until  the 
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ticket  is  paid  for.  A  script  instance  will  terminate  (i.e.  halt 
execution)  if  a  reservation  has  teen  cancelled  or  a  ticket  has  been 
issued  and  used.  Note  that  many  instances  of  this  script  can  be 
running  concurrently;  with  each  instance  representing  an  unigue 
purchase  of  an  airline  ticket. 

2.3,1  The  APN 

Because  of  the  size  of  the  APN  representing  the  above  airline 
reservation  system  it  is  presented  in  two  parts.  Figure  2- A  gives 
the  APN  configuration  for  acquiring  the  reservation  data  and  making 
the  reservation.  Figure  2-B  gives  the  APN  configuration  for 
purchasing  the  airline  ticket. 

The  APN  configuration  for  making  a  reservation  (figure  2-A) 
shows  a  Petri  net  configuration  for  obtaining  five  pieces  of  data 
one  at  a  time  in  any  order.  The  data  required  are  the  flight's 
number  and  date  and  the  passenger's  name,  address,  and  telephone 
number.  Note  that  the  flight's  number  and  date  are  the  only  data 
about  the  flight  the  script  needs  from  the  user  as  these  are  the 
keys  of  the  variable  class  FLIGHT  (see  Appendix  A) .  The  initial 
marking  of  the  APN  consists  of  the  "starting",  "waiting-flight#", 
"wait ing- date" ,  " waiting- name " ,  "waiting-address",  and 
"waiting-phone#"  states.  The  "request-info"  transition  is  the  only 
transition  initially  enabled  (i.e.  its  only  input  state  is 
initially  marked)  and  since  it  has  an  implied  true  condition  it 
requests  the  data  mentioned  above  and  then  fires.  The  firing  of  the 
"request- inf o"  transition  causes  a  token  to  be  removed  from  the 
"starting"  state  and  placed  in  the  "vaiting-f or-inf o"  state,  thus 
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enabling  the  five  data  gathering  transitions  "got-flight #», 
"got-date" ,  »got-name" ,  "got-address" ,  and  "got-phone#".  The  firing 
of  any  of  these  transitions  means  that  an  appropriate  piece  of  data 
(indicated  by  the  firing  transition's  name)  has  been  obtained. 

The  APN  shows  some  sophistication  in  obtaining  the  flight's 
date.  Once  a  date  has  been  obtained  (i.e.  the  '‘got-date" 
transition  has  fired  causing  a  token  to  be  removed  from  each  of 
states  " waiting- date"  and  "waiting-for-inf o"  and  a  token  to  be 
placed  in  the  "received-date"  state)  transitions  "bad-date"  and 
"good-date"  are  enabled.  If  the  input  date  is  less  than  two  days 
away  another  date  is  requested  and  the  "bad-date"  transition  fires 
causing  a  token  to  be  removed  from  the  "received-date"  state  and  a 
token  to  be  placed  in  each  of  states  "waiting-date"  and 
"wait ing- for- info" .  This  causes  the  "got-date"  transition  to  be 
enabled  again.  Note  that  the  "bad-date"  transition  may  fire  zero  or 
more  times  depending  on  the  number  of  invalid  input  dates.  On  the 
other  hand,  if  the  date  is  two  days  or  more  away,  then  the 
"good-date"  transition  will  fire  causing  a  token  to  be  removed  from 
the  "received-date"  state  and  a  token  to  be  placed  in  each  of  states 
"received-valid-date"  and  "waiting-for-inf o".  Integrity  checking  of 
the  four  other  data  items  would  also  be  desirable  but  in  order  to 
keep  the  size  of  the  APN  "reasonable"  this  was  not  done. 

Once  a  piece  of  data  has  been  obtained  it  cannot  be  changed 
unless  another  request  is  made  for  it.  Thus  once  the  flight's 
number  and  passenger's  name,  address,  and  telephone  number  have  been 
input  they  cannot  be  changed.  This  is  indicated  in  the  APN  by  the 
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fact  that  the  four  appropriate  data  gathering  transitions  can  only 
fire  once.  The  date  gathering  transition,  "got-date",  however  can 
fire  one  or  more  times  depending  on  the  validity  of  the  input  date 
(with  a  reguest  for  a  new  date  being  made  with  each  date  rejection). 

During  the  information  gathering  process  it  is  possible  that  no 
input  or  insufficient  input  may  be  forthcoming  after  a  suitable  time 
period.  To  take  care  of  this  case  we  have  the  transition 
"time-limit-exceeded”  which  fires  after  ten  minute  periods  of  no 
activity  (i.e.  a  token  remains  in  the  "waiting-f or-info"  state  for 
ten  minutes) .  The  firing  of  this  transition  causes  another  request 
to  be  made  for  any  information  not  yet  received.  Once  all  the 
states  "received-flight#",  "received-valid-date",  "received-name", 
"received-address",  and  "received-phone#"  are  marked  (indicating  the 
relevant  information  has  been  obtained)  the  "reserving- seat" 
transition  is  enabled  and  it  will  fire  once  the  reservation  has  been 
made.  The  firing  of  this  transition  removes  tokens  from  the  five 
states  mentioned  above  and  the  "w aiting- for-inf o"  state  and  places  a 
token  in  the  "waiting-payment"  state. 

The  A?N  configuration  for  purchasing  a  ticket  is  shown  in 
figure  2-B.  A  token  in  the  "waiting-payment"  state  causes  the 
"cancelling-without-payment"  and  "paying-now"  transitions  to  be 
enabled.  If  a  payment  is  not  made  within  one  day  of  the  flight  or 
the  passenger  explicitly  cancels  his  reservation  without  having  made 
a  payment  the  reservation  is  cancelled  and  the 
"cancelling-without-payment"  transition  fires.  APN  processing 
terminates  at  this  point  because  there  are  no  enabled  transitions 
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(i.e.  the  active  transition  set  is  empty).  On  the  other  hand,  if  a 
payment  is  made  at  least  one  day  in  advance  of  the  flight  date  the 
"paying-now"  transition  fires  causing  a  token  to  be  removed  from  the 
"waiting- payment"  state  and  placed  in  the  "payment-made"  state. 

A  token  in  the  "payment-made"  state  means  that  the 
"cash-payment",  "cheque-payment",  and  "credit-card-payment" 
transitions  are  enabled.  Only  one  of  these  can  fire  (depending  on 
whether  the  payment  is  made  using  cash,  cheque,  or  credit  card 
respectively)  and  this  happens  only  after  the  payment  amount  and 
method  has  been  recorded.  The  firing  of  one  of  these  transitions 
causes  a  token  to  be  removed  from  the  "payment-made"  state  and  a 
token  to  be  placed  in  the  "payment-recorded"  state.  Now,  depending 
on  whether  the  sum  of  all  payments  made  equals  the  cost  of  the 
ticket  or  not,  one  of  the  enabled  transitions  "full- payment"  or 
"partial-payment"  can  fire. 

If,  on  the  one  hand,  "full-payment"  is  the  firing  transition 
then  a  token  is  removed  from  the  "payment-recorded"  state  and  a 
token  is  placed  in  the  "ticket-purchase"  state  (indicating  that  the 
firing  of  the  "full- payment"  transition  has  caused  a  ticket  to  be 
issued  to  the  passenger) .  Now  one  of  enabled  transitions 
"cancelling- with- ticket"  or  "flight-left"  can  fire.  Depending  on 
which  transition  fires  a  token  is  removed  from  the  "ticket- issued" 
state  and  placed  in  either  the  "reservation-cancelled"  state  or  the 
"successful-purchase"  state.  The  " cancelling-w ith- ticket" 
transition  can  fire  only  if  the  passenger  has  explicitly  cancelled 
his  reservation  and  returned  his  ticket,  in  which  case  an 
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appropriate  refund  is  given-  The  "flight-left”  transition  fires  if 
the  current  time  equals  the  flight  time  (i-e.  the  flight  is 
leaving)  .  The  firing  of  either  of  these  transitions  causes  APN 
processing  to  terminate  as  the  active  transition  set  will  be  empty. 

If,  on  the  other  hand,  "partial-payment"  is  the  firing 
transition  then  a  token  is  removed  from  the  "payment- recorded "  state 
and  a  token  is  placed  in  the  "partial-payment-made"  state.  A  token 
in  the  this  state  means  that  the  "cancelling-wi th-payment"  and 
"making-more-payment"  transitions  are  enabled.  The 
"cancelling-with-paymen t"  transition  will  fire  if  the  passenger  has 
either  explicitly  cancelled  his  reservation  or  it  is  less  than  one 
hour  before  the  flight.  Before  this  transition  fires  a  refund  is 
made  of  all  partial  payments  (with  the  refund  method  depending  on 
the  payment  method (s) ) .  Once  it  has  fired  a  token  is  removed  from 
the  "partial-payment-made"  state  and  placed  in  the 
"reservation-cancelled"  state.  At  this  point  APN  processing  again 
terminates  as  the  active  transition  set  will  be  empty.  If,  on  the 
other  hand,  another  payment  is  recorded,  the  "making-more-payment" 
transition  fires.  A  token  is  removed  from  the 
"partial-payment-made"  state  and  placed  in  the  "payment- made "  state 
thus  enabling  the  "cash-payment",  "cheque-payment",  and 
"credit-card-payment "  transitions.  APN  processing  now  continues  as 
already  outlined  above. 

2. 3. 2  The  Script 


To  enhance  the  readibility  of  the  script  example  given  in  this 
section  we  present  a  short  introduction  to  the  syntactic  form  of 
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scripts.  Scripts  have  three  property  categories:  a  parameter  list, 
a  local  variable  declaration  list,  and  a  transition  list.  The 
values  passed  to  a  script  instance  through  its  parameter  list  are 
used  to  uniquely  identify  that  script  instance.  The  local  variable 
declaration  list  is  used  to  declare  all  parameter  and  local  variable 
properties.  Local  variables  can  be  used  to  either  hold  values  for 
computation  within  a  script  or  to  act  as  states.  These  state 
variables,  which  have  names  corresponding  to  the  states  of  the 
script's  representative  APN,  are  restricted  to  having  values  of  'on' 
or  'off'.  Each  transition  property  in  the  transition  list 
corresponds  directly  to  the  transition  of  the  same  name  in  the 
script's  representative  APN.  The  from  and  to  properties  of  a 
transition  specify  the  input  and  output  states  of  that  transition. 
The  conditions  and  actions  properties  are  boolean  and  non-boolean 
expressions,  respectively,  as  allowed  in  TAXIS  (see  Appendix  A) , 
with  additional  boolean  and  non-boolean  expressions,  such  as  those 
related  to  dialogues,  also  allowed.  For  example,  a  s-inf orm  command 
passes  data  values  to  a  script  user  while  a  u-inf ormed  predicate 
checks  if  user  has  supplied  some  specified  information.  Also  a  user 
can  employ  u- inform  commands  to  pass  data  values  to  script  instances 
that  have  requested  these  values  using  s- request  commands. 

The  coding  of  the  TAXIS  script  for  the  above  described  airline 
ticket  acquisition  system  is  given  below.  Notice  how  it  corresponds 
with  its  representative  APN  (as  in  figures  2- A  and  2-B) . 

SCRIPT-CLASS  ACQUIRS-TICKET  with 
parameter-list 

acquire-ticket :  (reservation# , travel-agent) ; 
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locals 

reservation#:  RES-NUM; 

travel-agent:  TRAVEL- AGENT ; 

p:  PERSON; 

flight:  FLIGHT; 

f#:  { | 1: : 999 | } ; 

date:  DATE-VALUE; 

time:  TIME-VALUE; 

payment-amt,  payment-to-date:  MONEY; 
payment-method:  {J  'cash*,  'cheque* ,  'credit'  |}; 
reservation-cancelled,  returning-ticket ,  ticket-issued:  BOOLEAN; 
date-status:  [1  'good',  'bad'  |  ]; 

starting  default  'on',  waiting- flight#  default  'on', 
waiting-date  default  'on',  waiting-name  default  'on', 
waiting-address  default  'on',  waiting-phone#  defa ult  'on', 
waiting-for-info,  received-flight#,  received-date, 
received- valid-date,  received-name,  received- address, 
received- phone#,  waiting- pa ymen t,  reservation-cancelled, 
payment-made,  payment-recorded,  partial-payment-made, 
ticket-purchase,  successful-purchase:  STATE; 

transit ion- list 


request-info : 

from  fl:  starting; 

to  tl:  waiting-for-info; 

actions 

ask- for-info:  s-reauest (travel- agent. code  ,  f#,  date,  p.name, 

p. address,  p. phone#); 

/*  The  script  user  must  supply  the  script  with 
these  values  by  employing  u-inf orm  commands  */ 
set-time:  time  < —  current- time ;  /*  current-time 
is  a  system  variable  containing  the 
current  time  in  seconds  */ 
end  reguest-info; 

got-f light# : 

from  fl:  waiting-for-info; 

f2:  waiting- flight#; 
to  tl :  waiting-for-info; 

t2:  received-flight#; 
conditions 

is-f light #-known? :  u- informed  (travel-agent,  code,  f#)  ; 
actions 

reset- time:  time  < —  curren t-time ; 
end  getting- flight# ; 

got-date: 

from  fl:  waiting-for-info; 

f2:  waiting-date; 
to  tl:  received-date; 
conditions 

is-date-known? :  u-inf ormed  ( travel- agent. code,  date); 
actions 
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reset- time:  time  <--  current- time : 
end  getting-date; 

bad-date: 

from  fl:  received-date; 
to  t 1 ;  waiting-date; 

t2:  waiting-for-info; 
conditions 

date-bad?:  date-difference  (date)  <=  1; 

/*  date-difference  is  a  transaction  that  returns 
the  number  of  days  it  differs  from  the  current 
date.  Note  that  since  the  date  is  an  instance  of  the 
class  DATE-VALUE  it  exists  in  form 
dd/mm/yy.  */ 

actions 

bad-date:  date-status  < —  'bad'; 

tell-user:  s-  inform  (tra  ve  1-agent,  code ,  date-status); 
get-new-date:  s-reguest  (travel-agent,  code ,  date); 
end  bad-date; 

good-date: 

from  fl:  received-date; 
to  tl:  waiting-for-info; 

t2:  received-valid^date; 
conditions 

date-good?:  date-difference  (date)  >  1; 
actions 

good-date:  date-status  <--  'good* ; 

tell-user:  s-inform  ftravel- agent. code,  date-status); 
end  good- date; 

got-name: 

from  fl:  waiting-for-info; 

f2:  waiting-name; 
to  tl:  waiting-for-info; 

t2:  received-name; 
conditions 

is- name-known?:  u- in formed ftravel- agent. code,  p.name)  ; 
act  ions 

reset-time:  time  < —  current-time; 
end  getting-name 

got-address : 

from  fl:  waiting-for-info; 

f2:  waiting-address; 
to  tl :  waiting-for-info; 

t2:  received-address; 
conditions 

is-address-known? :  u- informed  {travel-agent. code,  p. ad dress); 
actions 

reset-time:  time  < —  current-time; 
end  getting-address; 

got-phone#: 

from  fl:  waiting-for-info; 
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f2:  wainting-phone# ; 
to  1 1 :  waiting- for-info ; 

t2:  received-phone#; 
conditions 

is-phone#-known? :  u- inf or me d  f travel- a pent .code ,  p. phone#)  ; 
actions 

reset-time:  time  <--  current-time; 
end  getting-phone#; 

t ime- limit-exceeded : 

from  f 1 s  waiting- for-info ; 
to  tl:  waitin g-for-info; 
conditions 

exceeded-time-limit:  {current-time  -  time)  >  600; 

/*  600  seconds  =  10  minutes  */ 

actions 

is-f light #-known? :  if  (f#  =  unknown) then 

s-reguest  {travel- agent,  code  ,  f#)  ; 
is-date-known?:  if  (date  =  unknown)  then 

s- regues t (travel- agent -code ,  date) ; 
is-date- incorrect?:  if (date-difference (date) <  =  1 ) then 

s- request  ftra  vel-  agent .  code  ,  date); 
is- name-known?:  if  (p.  name  =  unknown)  then 

s- request ( travel -agent .code,  p .name) ; 
is-address-known? :  if  (p. address  =  unknown) then 

s-reguest (travel- agent . code , 
p. address) ; 

is-phone#-known? :  if  (p. phone#  =  unknown) then 

s-reguest  (travel-agent,  code,  p.  phone#)  ; 
/*  Note  that  we  could  use  Uninformed  predicates  in  the 
above  five  actions  instead  of  having  checked  if  the 
variables  had  value  unknown.  For  example,  instead 
of  checking  f#  =  unknown  we  could  have  checked  if 
u- informed (travel- agent. code ,f#) ■  */ 

end  time-limit-exceeded; 

re serving- seat: 


from 

f  1: 

received- f light# ; 

f  2 : 

received- valid -date; 

f  3 : 

received-name; 

f  4 : 

received-address ; 

f  5 : 

received- phone#; 

f  6: 

waitin g-for-info; 

to 

tl : 

waiting-payment; 

actions 

make-reservation:  reserve-seat  (p,  (f #,date) . flight) ; 

/*  See  Appendix  A  for  details  of  the 
reserve- seat  transaction  */ 
tell- ticket-cost :  s-inform  (travel- agent. code, 

(f#,date)  .  f  lig  ht .  ticket-co  st)  ; 
ask-f or-payment-inf o:  ^-request  (travel-agent. code , 

payment-amt, payrae nt-method) ; 
/*  Note  that  informing  the  IIS  of  a  payment 

amount  and  method  is  enough  to  make  a  payment. 

A  more  sophisticated  IIS  might  actually 
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require  an  electronic  transfer  of  funds  at 
the  time  of  the  purchase.  */ 
cancelling?:  s-reguest (travel- agent. code, 

reservation-cancelled)  ; 

/*  For  a  user  to  actually  supply  values  to 

local  variables  payment-amt,  payment- meth od , 
and  reservation-cancelled  he  must  execute 
appropriate  u-inf orm  commands.  See  the 
dialogue  example  of  the  next  section  for  an 
illustration  of  this.  */ 

end  reserving-seat; 

cancel ling- without- payment: 
from  fl:  waiting- pa yment ; 
to  tl:  reservation-cancelled; 
conditions 

cancel?:  ( (date-difference  (date)  <=  1)or 

(reservation-cancelled  =  true) )  ; 

actions 

cancel-reservation:  cancel-seat  (p,  (f#,date)  .  flight)  ; 

/*  The  cancel-seat  transaction  cancels  the 
appropriate  reservation  by  removing  the 
tuple  uniquely  identified  by  its  parameters 
from  the  RESERVATION  relation  */ 
ticket-not-issued :  ticket-issued  < —  false: 
tell-user:  s-  inform  (travel- agent,  code ,  ticket-issued); 
end  cancelling-without- pa yment ; 

paying-now: 

fpom  fl:  waiting-payment 
to  tl:  payment-made ; 
conditions 

paying-now?:  not  l  (payment-amt  =  unknown) 

or  (payment-method  =  unknown) ) : 

actions 

save-amt:  pay ment-to-da te  < —  payment-amt; 
tell-user- payment-amt :  s- inform  (travel-agent. code , 

payment-to-date) ; 

end  paying-now; 

cash-payment: 

from  fl:  payment-made; 
to  tl:  payment-recorded; 
conditions 

cash?:  payment-method  =  ‘cash1; 
actions 

record-payment:  record-cash  (p , (f#,date) .flight, 
payment-amt) ;  /*  This  transaction  updates 
the  cash  payment  amount  of  person  p  for  flight 
(f #, date) . flight.  The  initial  cash  amount  is 
assumed  to  be  0  */ 
end  cash-payment; 

cheque- payment: 

from  fl:  payment-made; 
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to  t 1 :  payment-recorded; 
conditions 

cheque?;  payment-method  =  'cheque*; 
actions 

record-payment;  record-cheque  (p, (f#,date) .flight, 
payment-amt) ;  /*  This  transaction  updates 
the  cheque  payment  amount  of  person  p  for  flight 
(f#, date)  .  flight.  The  initial  cheque  amount  is 
assumed  to  be  0  */ 
end  cheque-payment; 

cr edit- card- payment ; 
from  f 1 :  payment-made; 
to  t 1 :  payment-recorded; 
conditions 

credit?;  payment-method  =  'credit'; 
actions 

record-payment:  record-credit (p,  (f#,date) .flight, 
payment-amt) ;  /*  This  transaction  updates 
the  credit  card  payment  amount  of  person  p  for  flight 
(f #, date) . flight,  the  initial  credir  card  amount  is 
assumed  to  be  0  */ 
end  credit-card-payment; 

full- payment; 

from  f 1 ;  payment-recorded; 
to  tl:  ticket-purchase; 
conditions 

full-payment?;  (payment-to-da te  = 

(f#,date)  .  flight  .ticket-cost)  ; 

actions 

issued-ticket ;  ticket-issued  < —  true; 

tell-user;  s-inform  (travel- agent . code ,  ticket-issued); 

returning-ticket? :  s-reguest (travel-agent. code, 

returning-ticket) ; 

end  full-payment; 

parti al-payment ; 

from  fl:  payment-recorded; 
to  tl;  partial-payment-made; 
conditions 

partial-payment?;  {payment- to- date  < 

(f#,date)  . flight,  ticket-cost)  ; 

actions 

ask-f or- more- payment ;  s- request (travel- agent .code , 

payment-amt , payment-method) ; 
reset-payment-amt;  payment-amt  <--  unknown; 
reset-payment-method:  payment-method  < —  unknown; 
end  partial- payment ; 

flight-left; 

from  fl;  ticket-purchase; 
to  tl:  successful-purchase; 
conditions 

flight-left?:  (f #, date) . flight. time  <=  current-time; 
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actions 

f light-not-cancelled :  re ser vation- cancelled  < —  false : 
t ell- user :  s- inform (travel- agent. code , 

reservation-cancelled) ; 

end  flight-left; 

cancelling-with-ticket: 
from  f 1 :  ticket-purchase; 
to  tl:  reservation-cancelled; 
conditions 

cancel?:  (reservation-cancelled  =  true)  and 
(returning-ticket  =  true) ; 

actions 

cancel-reservation:  cancel-  seat  (p,  (f#,date)  .flight)  ; 
give-refund:  give-ref  und  (p,  (f#, date)  .  flight)  ; 
no-ticket:  ticket-issued  <--  false: 

tell-user:  s-inf orm (travel-agent. code,  ticket- issued)  ; 
end  cancelling-with-ticket; 

making- more- payment: 

from  fl:  partial-payment-made; 
to  tl:  payment-made; 
conditions 

more-payment?:  not  (  (payment-amt  =  unknown) 

or  (pay ment-method  =  unknown) )  : 

actions 

add-payment-amt:  payment- to-date  < —  payment-to-date 

+  payment-amt; 

tell- user -tot al-paid:  s-inf orm (travel- agent. code, 

payment-to-date) ; 

end  making-more-payment; 

cancel ling- with- payment: 

from  fl:  partial-payment-made; 
to  tl:  reservation-cancelled; 
conditions 

cancel?:  (current-time  -  (f  #,  date)  .  flight .  time)  <  360  0 
or  (reservation-cancelled=true) ; 

actions 

cancel-reservation:  cancel-seat  (p,  (f  #,date)  .  flight)  ; 
give-refund:  give-ref und  (p,  (f#,date) .flight)  ; 
ticket-not-issued:  ticket-issued  < —  false: 
tell-user:  s-inf orm  (travel- agent. code,  ticket-issued); 
/*  give-refund  is  a  transaction  that  gives 

a  refund  of  partial  payment  (s).  Refund  method 
is  determined  by  the  one  or  more  payment 
methods  used.  */ 
end  cancelling-with- payment ; 


end  ACQUIRE-TICKET; 
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The  "parameter-list"  and  "locals"  properties  of  a  script  are 
the  same  as  for  transactions.  The  "parameter-list"  property  of  the 
above  script  defines  a  definitional  property  whose  subjects  are 
RES-NUM  and  TRAVEL-AGENT,  whose  attribute  is  acguire-ticket,  and 
whose  value  is  the  script  definition  ACQUIRE-TICKET.  Instances  of 
RES-NUM  and  TRAVEL-AGENT  define  factual  properties  whose  values  are 
instances  of  the  ACQUIRE-TICKET  script.  The  RES-NUM  class  is  a 
finitely  defined  class  that  is  declared  as: 

RES-NUM :  =  { |  10000:  :  99999  |}; 

The  TRAVEL-AGENT  class  is  IS-A  the  USER  class  which  in  turn  is  IS-A 
the  PERSON  class.  The  USER,  PERSON,  and  TRAVEL-AGENT  classes  are 
declared  as: 


VARIABLE-CLASS  PERSON  with 
keys 

person:  (name, address)  ; 
characteristics 

name:  PERSON-VALUE; 
address:  ADDRESS- VALUE ; 
phone#:  PHONE-VALUE; 
attributes 

age:  AGE-VALUE; 
end  PERSON; 


VARIABLE-CLASS  USER  isa  PERSON  with 
keys 

user:  (name, address) ; 
characteristics 

name:  USER-PERSON- VALUE; 
address:  USER- ADDRESS-VALU E; 
attributes 

code:  USER-CODE; 
logged-on?:  BOOLEAN; 
end  USER; 


VARIABLE-CLASS  TRAVEL- AGENT  isa  USER  with 
keys 

travel-agent: (name , address) ; 
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attributes 

travel-agency:  TRAVEL- AGENCY ; 
end  TRAVEL-AGENT; 

Thus  TRAVEL-AGENT,  through  specialization,  inherits  all  the 
properties  of  both  USER  and  PERSON.  For  example,  a  travel  agent  has 
both  a  telephone  number  and  a  code.  The  code  property  serves  as  a 
password  that  the  system  uses  to  uniquely  identify  the  travel  agent 
when  he  is  logged  on  to  the  system.  A  code,  rather  than  a  terminal, 
is  employed  as  identification  so  that  a  user  can  logon  any  available 
terminal  rather  than  being  restricted  to  just  one.  Note  that  the 
classes  of  the  name  and  address  attributes  of  TRAVEL-AGENT  are 
USER-PERSON-VALUE  and  USER- ADDRESS- VALUE  respectively  rather  than 
PERSON-VALUE  and  ADDPESS- VALUE.  This  is  because  USER,  rather  than 
PERSON,  is  the  next  most  immediate  generalization  of  TP AVEL -AGENT. 
Cf  course,  USER-PERSON-VALUE  and  USER-ADDRESS- VALUE  must 
respectively  be  IS-A  PERSON-VALUE  and  ADDRESS-VALUE. 

The  "locals"  property  in  the  above  script  is  used  to  declare 
the  local  variables  and  parameters  of  the  script.  Included  as  local 
variables  are  the  state  variables  (representing  states  in  the 
script* s  corresponding  APN)  which  are  declared  to  be  of  class  STATE. 
As  such,  they  can  have  values  of  *on*  or  'off*  (or  un know n) .  A 
marked  state  is  represented  by  its  state  variable  having  a  value  of 
'on';  similarly  an  unmarked  state  is  represented  by  its  state 
variable  having  a  value  of  either  'off*  or  unknown  (with  unknown 
indicating  an  uninitialized  state  variable) .  The  six  states  in  the 
airline  ticket  acquisition  script  that  are  initially  marked  are 
given  the  value  of  'on*  using  the  default  clause  [see  Wong  80]  when 
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they  are  declared. 

The  "transit ion- list"  properties  consist  of  all  the  transitions 
in  the  script.  Each  transition  class  has  its  input  states  listed  in 
its  "from"  properties  and  its  output  states  listed  in  its  "to" 
properties.  A  transition  is  enabled  if  all  its  input  states  have 
tokens  in  them.  The  firing  of  a  transition  causes  a  token  to  be 
removed  from  each  of  its  input  states  and  a  token  to  be  placed  in 
each  of  its  output  states.  An  enabled  transition  will  be  executed 
if,  when  checked,  all  its  conditions  properties  are  true  (in  which 
case  all  its  actions  properties  are  carried  out  and  the  transition 
is  said  to  have  fired) .  If  no  conditions  are  present  (as  in  the 
"reguest- info"  transition)  the  condition  is  assumed  to  be  true. 
Thus  the  "request-info"  transition  will  be  executed  immediately  upon 
execution  of  the  script  as  it  is  the  only  transition  initially 
enabled.  A  firing  transition  executes  all  its  actions  in  sequential 
order.  The  action  properties  permitted  in  transitions  are  a 
superset  of  those  permitted  in  transactions,  because  additional 
statement  types  specific  to  scripts  are  also  allowed. 

One  such  set  of  statements  are  those  for  writing  dialogues 
between  the  user  and  the  system.  Thus 

s-reguest  (travel- agent. code, f # ,date, p. name, p. address, p . phone#) 

asks  the  user  identified  by  the  value  of  travel-agent .code  for  the 
values  of  f#,  date,  p.name,  p. address,  and  p. phone#.  This  command 
appears  in  the  "ask- for-inf o"  property  of  the  "request-info" 
transition  in  the  above  script. 
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To  respond  to  a  s-reguest  command,  a  script  user  would  execute 
one  or  more  u-infor m  commands.  The  first  argument  of  the  u-inf orm 
command  uniquely  identifies  the  script  instance,  while  the  other 
arguments  supply  the  appropriate  values  to  that  script  instance. 
These  values  must  be  constant  expressions.  Thus  the  statement 

u-inf  orm  (acquire-tic ket  (  10628  ,  joe-agent)  ,f  #< — 007) 

supplies  an  instance  of  the  script  ACQUIRE-TICKET  (uniquely 
identified  by  the  keys  10628  and  joe-agent)  a  value  of  007  for  f#. 
An  s-reguest  for  a  p-value  must  have  been  executed  before  a  u ^inform 
for  that  p-value  can  be  successfully  executed.  Another  command, 
s-inform,  is  similar  to  u-inf orm  except  a  script  instance  uses  it  to 
provide  a  user  with  p-values  and  no  u-reg uest  has  to  be  executed 
beforehand  for  any  of  the  p-values  supplied  by  it.  Note  that  before 
an  s-inform  or  s-reguest  command  can  be  successfully  executed,  the 
user  named  in  the  first  argument  must  be  logged  on  to  the  system; 
if  he  isn't,  the  s-inform  or  s-reguest  command  must  "wait”  until  he 
is.  It  is  possible  to  avoid  long  waiting  periods  by  checking  if  a 
user  is  logged  on  the  system  before  attempting  to  communicate  with 
him.  This  can  be  done  by  testing  if  the  "logged-on?"  attribute  of  a 
particular  instance  of  USER  is  true  or  false. 

To  gain  knowledge  about  a  dialogue  that  has  occurred  in  the 
past  we  have  predicates  such  as  u-inf ormed.  This  predicate  checks 
if  one  or  more  u- inform  commands  have  been  successfully  executed  by 
the  user  named  in  its  first  argument  to  supply  the  script  with 
p-values  for  its  other  arguments.  Thus  execution  of 
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u-inform (acguire-ticket  ( 10628 , joe-agent)  , f#< — 007) 

would  cause  the  " is-f light #-known"  condition  property  of  the 

Mgetting-f light#"  transition 

u-informed  (travel-agent,  code, f #  ) 

to  return  true  upon  evaluation.  If  an  appropriate  u-inform  command 
to  supply  f#  with  a  value  had  not  been  executed  it  would  return 
false.  A  complete  discussion  of  all  the  dialogue  commands  and 
predicates  available  for  use  in  TAXIS  scripts  is  given  in  Chapter  3 
and  examples  of  their  use  are  given  throughout  the  remainder  of  this 
thesis. 

If  for  some  reason  the  transaction  reserve-seat  of  the 
"reserving-seat"  transition  cannot  make  a  reservation  an  exception 
instance  should  be  raised  within  the  transaction.  The  exception 
handler  must  be  specified  in  the  "make-reservation"  property  of  the 
"reserving-seat"  transition.  As  such  it  could  be  another  script 
that  would  find  an  alternate  flight  and  then  acquire  a  ticket  for 
the  passenger  on  that  flight.  The  script  exception  handling 
mechanism  (which  is  very  similar  to  the  transaction  exception 
handling  mechanism)  is  presented  in  Chapter  3  and  illustrated  in 
Chapter  4. 

2.3.3  A  Dialogue  Example  Using  the  AC QUIRE-TICKET  Script 

We  give  here  an  example  of  how  the  script  ACQUIF E-TI CKET  can  be 
used  to  generate  a  dialogue  between  the  user  and  the  system. 
Consider  the  following  scenario  of  events.  A 


passenger. 
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' joe- passenger ' ,  wishes  to  reserve  a  seat  on  January  1f  1  980  for 
flight#  007  on  January  8,  1980.  The  ticket  agent,  *  joe-agent*, 

makes  the  reservation  by  creating  an  instance  of  the  script  with 
reservation#,  10628,  and  ticket-agent,  joe-agent,  as  the  arguments. 
He  only  gets  the  flight#  and  passenger  name  entered  before  he  is 
interrupted  by  a  telephone  call  which  takes  more  then  ten  minutes. 
After  he  is  finished  with  the  telephone,  he  enters  the  rest  of  the 
reguired  information  but  with  the  incorrect  flight  date  of  January 
2,  1980.  After  the  system  points  this  out  to  him  and  he  has 

corrected  his  mistake  the  reservation  is  made.  The  passenger  does 
net  pay  right  away;  instead  on  January  3,  1980  he  pays  $300.00  by 
cash,  on  January  5,  1980  he  pays  $300.00  by  cheque,  and  on 
January  6,  1980  he  pays  the  remaining  $200.00  by  credit  card.  On 

January  7,  1980  he  decides  he  cannot  make  the  flight  and  so  cancels. 

We  assume  that  joe-agent  is  an  instance  of  TRAVEL- AGENT  (and 
thus  of  USER  and  PERSON)  and  the  value  of  joe-agent. code  is  simply 
*  joe-agent*.  That  is,  to  enhance  readibility,  we  let  the  user's 
code  be  his  name.  The  above  scenario  of  events  would  result  in  the 
following  dialogue: 

joe-agent:  instantiate  ACQUIR E-TICK ET (1 062 8, joe-agent) 

aeguire-t icket  (10628, joe-agent)  :  s- re guest [ 1 loe-agent *  .  f#,  date, 

p.  name,  p. address,  p. phone#) 

joe-agent:  u- inf orm (acguire-t icket  ( 10628 , joe-agent) ,  f#  < —  0  07, 
p.name  < —  'joe-passenger') 

/*  After  ten  minutes  of  no  activity  (i.e.  while 
the  travel  agent  is  answering  the  telephone)  */ 

acguire-ticket  (10628, joe- agent) :  s-reguest  l ' ioe-agent ' .  date, 

p. address,  p.phoDe#) 
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joe-agent:  u-inform  (acguire-t icket (  10628f  joe-agent)  r  p. address 
< —  '1-passenger-lane',  p. phone#  < —  123-4567, 
date  < —  02/01/80) 

acguire-t icket  {10  6  28, joe- agent)  :  inform  { ' joe- agent* , 

date-status  < —  *bad*) 

s- re  guest  l 1  ioe-aqent 1 .  date) 

joe-agent:  u-inform  facguire-t icket  (10628. joe-agent) .  date 
< —  08/01/80) 

acqui re-ticket  (10  6  28, joe- agent)  :  s- inform ( *  joe- a gent* , 

date-status  < —  *good*) 
s-inf orm  ( ' joe-agent  * , 

(007,08/01/80) . flight. ticket. cost 
< —  $800.00) 
s-  request  ( *  joe-agent  * , 
payment-amt,  payment-method) 
s- request { 'joe-agent ' , 
re  servation- cancel  led) 

joe-agent:  u- inform  facguire-t icket  (1062 8. ioe-agen t) , 

payment-amt  <--  $3 00 . 0 0 , payment-method  < —  *cash*) 

acqui re- ticket  (10  6  28, joe- agent) :  s- inform ( ' joe- agent ' , 

pa yment-to-date  < —  $300.00) 
s- re  quest  {'joe-agent ' , 
payment-amt, payment-method) 

joe-agent:  u-inform (acguire-t icket ( 10628, joe-agent) , 

payment-amt  <--  $300. 00,  payment-method  < —  'cheque') 

acguire-t icket (10628, joe-agent) :  s- in  f  o  rm  ('joe-agent*  , 

payment-to-date  < —  $600.00) 
s- request ( 'joe-agent ' , 
pa  yment-amt , payment- method) 

joe- a gent:  u-inform  facguire-t icke t  ( 10628, joe-agent) , 

payment-amt  <--  $200. 00, payment-method  < —  'credit') 

acquire-ticket  (10628, joe-agent) :  s- inform  ( ' joe-agent ' , 

payment-to-date  < —  $800.00) 
s-inf orm  ( ' joe-agent ' , 
ticket-issued  <--  true) 
s- request  ('joe-agent ' , 
returning- ticket) 

joe-agent:  u-inform  facguire-t  icket  f  10628,  ioe-aqent)  , 

returning-ticket  < —  true, reservation-cancelled  <--  tr ue) 

acguire-t icket  (10628, joe- a gent) :  s-inf orm ( ' joe-agent  * , 

ticket-issued  < —  false) 
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Additional  dialogue  can  be  created  by  using  u- request .  For 
example  suppose  we  wish  to  know  the  flight  time.  We  can  find  this 
by: 

joe-agent:  u- request  f  acquire-  ticket  (1  0628 ,  joe -agent)  , 

(007,08/01/80) .flight. time) 

which  could  cause  the  system  to  respond: 

acguire-t icket  (10628, joe-agent) :  s- inform ( *  joe-agent 1 , 

(0  07,08/01/80)  .flight. time 
< —  12:45  pm) 

If  we  wished  to  find  information  such  as  all  the  prices  and  times  of 
all  flights  leaving  from  Toronto  to  Boston  between  05/01/80  and 
10/01/80  we  would  have  to  execute  an  appropriate  get -obi ect 
operation  on  the  database.  This  would  be  done  by  using  another 
script  which  would  build  and  execute  the  get- object  statement  using 
appropriate  dialogue.  Note  that  we  cannot  execute  a  u- request 
command  for  data  the  script  does  not  have  access  for.  Thus,  for 
example,  we  cannot  retrieve  reservation  data  from  the  ACQ UIRE-TIC KET 
script  as  the  variable  class,  RESERVATION ,  is  not  accessable  in  it. 

2.J..4  Specialisation  of  the  ACQUIRE-TICKET  Script 

We  can  specialize  TAXIS  scripts  in  the  same  ways  as  for  other 
TAXIS  classes  (see  [ Mylopoulos  et  al  78a,  78b,  and  79]  and 
[Wong  80]).  Scripts,  like  transactions,  can  be  specialized  in  two 
ways,  which  we  call  explicit  and  implicit  specialization  (see 
Appendix  A  for  examples  of  transaction  specialization  using  these 
two  technigues) .  Full  details  on  all  allowed  specializations  of  the 
different  script  properties  are  given  in  Chapter  3. 
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As  an  example  of  script  specialization  consider  refining  the 
script  presented  above  for  acquiring  an  airline  ticket  to  one  for 
acquiring  a  charter  airline  ticket.  A  charter  reservation  must  be 
made  and  paid  for  (in  one  lump  sum)  at  least  sixty  days  in  advance 
cf  the  flight.  A  passenger  may  cancel  his  reservation  and/or  cash 
in  his  ticket  any  time  up  to  sixty  days  before  the  flight.  However, 
once  the  flight  is  sixty  days  or  less  away  a  refund  is  not  possible 
under  any  circumstances. 

The  following  script  definition  for  acquiring  a  charter  airline 
ticket  demonstrates  explicit  specialization. 


SCRIPT-CLASS  ACQUIRE-CHARTER-TICKET  isa  ACQUIRE-TICKET  with 


parameter-list 

acguire-charter-t icket: (reservation#, travel-agent) ; 


locals 

reservation#:  CHARTER-RES-NUM ; 


transit ion- list 


good-date: 

conditions 

good-date?:  dat e-difference  (date)  >  60; 
end  good-date; 

bad-charter-date : 

from  fl:  received-date; 
to  tl:  waiting-date; 
conditions 

bad-date?:  date-difference (da te)  <=  60; 
actions 

bad-date:  date-status  < — ■  *  bad'; 

tell-user:  s-inform  (travel- agent. code,  date-status); 

ask-new-date:  s-  request  (travel- agent. code,  date); 
end  bad-charter-date; 

cancelling-charter: 

from  fl:  waiting-payment; 
to  tl:  reservation-cancelled; 
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conditions 

cancel?:  ( (date-dif fere  nee  (da  te)  <=  60)  or 
(reservation-cancelled  =  true) )  ; 

actions 

cancel-reservation:  cancel-seat  (p,  (f#,date) .flight)  ; 
ticket-not-issued:  ticket-issued  < —  false: 
tell-user:  s- inform  Itra vel-agent.code ,  ticket-issued); 
end  cancelling-charter; 

paying- now: 
conditions 

full- pay  ment? :  (payment-amt  =  (f#,  date)  .  flight .  ticket-0  ost)  ; 
end  paying- now; 

ref und- impossible: 

from  fl:  ticket-purchase; 
to  tl:  successful-purchase; 
conditions 

after-60-days?:  date-difference (date)  <=  60; 
end  refund-impossible; 

end  ACQUIRE-CHARTER-TICKET; 


Notice  that  the  ACQUIRE-CHARTER-TICKET  script  is  declared  to  be 
’•isa”  ACQUIRE-TICKET.  This  means  that  all  properties  of  the 
ACQUIRE-TICKET  script  not  newly  specified  or  specialized  in  the 
ACQUIRE-CHARTER-TICKET  script  are  inherited  from  ACQUIRE-TICKET. 
The  "parameter-list"  and  "locals"  properties  of 
ACQUIRE-CHARTER-TICKET  show  the  specialization  of  the  script* s  first 
parameter,  reservation#,  from  RES-NUM  to  CHARTER-RES-NUM.  (That  is, 
CHART ER-F.ES-NUM  IS-A  RES-NUM)  . 


Similarly,  all  transitions  not  specialized  in 

ACQUIRE-CHARTER-TICKET  are  inherited  from  ACQUIRE-TICKET.  The 
"good-date"  transition  has  its  "good-date?"  condition  specialized. 
Thus  date-difference  (date)  >  60  must  (as  it  does)  imply 

date-difference (date)  >  1.  However  the  converse  does  not  hold. 
That  is,  date-difference  (date)  <=  60  does  not  imply 


AN  AIRLINE  TICKET  ACQUISITION  SYSTEM 


Page  34 


CHAPTER  2 

date-diff erence (date)  <=  1.  As  a  result*  we  cannot  specialize  the 
"bad-date”  transition  and  so*  instead,  we  introduce  a  new  transition 
called  "bad-charter-date"  which  has  the  same  actions  as  "bad-date" 
but  checks  for  dates  less  than  sixty-one  days  away.  It  is  important 
to  note  here  that  we  have  not  removed  the  "bad-date"  transition. 
Cnee  a  date  has  been  received  (indicated  by  a  token  in  the  state 
"received-date")  the  three  transitions  "good-date"  (which  has  been 
specialized) ,  "bad-date"  (which  is  inherited  intact  f ron 
ACQUIRE-TICKET) ,  and  "bad-charter-date"  (which  is  new)  will  be 
enabled.  For  most  invalid  charter  dates  "bad-charter -date"  will 
most  likely  be  the  firing  transition  but  it  is  possible  that  if  a 
charter  reservation  were  attempted  for  a  date  less  than  two  days 
away  "bad-date"  rather  than  "bad-charter-date"  could  be  the  firing 
transition.  It  should  not  make  any  difference  which  of  several 
enabled  transitions  fires  if  their  conditions  are  true 
simultaneously.  If  it  does  then  the  APN  has  been  designed 
incorrectly.  (If  we  wish,  we  can  specialize  the  conditions  of  any 
transition  we  do  not  want  to  fire  in  a  more  restricted  situation  to 
always  be  false.  Although  this  is  legal*  it  violates  the  spirit  of 
TAXIS)  . 

Again*  because  the  condition  in  the 

"cancelling-without-payment"  transition  cannot  be  satisfactorily 
specialized,  we  introduce  a  new  transition  "cancelling-charter" 
which  will  cancel  a  charter  flight  reservation  if  the  current  date 
is  sixty  days  or  less  away  (and  the  passenger  hasn't  yet  bought  his 
ticket)  or  the  passenger  has  explicitly  cancelled  his  reservation. 
Its  actions  are  the  same  as  those  of  "cancelling-without-payment" 
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and  similar  comments,  made  concerning  '’bad-date1'  and 
"lad-charter-date"  above,  apply  to  it.  The  transition  "paying-now" 
is  specialized  by  having  a  new  condition  "full-payment"  added  to 
ensure  that  the  payment  amount  is  egual  to  the  ticket  cost  (to 
satisfy  the  lump  sum  payment  requirement).  It  should  be  noted  here 
that  the  old  condition  "paying-now?"  is  inherited  and  that  both 
conditions  must  be  true  before  the  specialized  "paying-now" 
transition  can  fire.  Finally  to  ensure  that  no  refund  is  given  for 
a  ticket  when  it  is  sixty  days  or  less  before  a  flight  we  introduce 
a  new  transition  "refund-impossible".  The  effect  of  this  transition 
is  to  terminate  the  script  because  in  the  wake  of  its  firing  no 
ether  transitions  in  the  script  will  be  enabled  and  so  the  active 
transition  set  will  be  empty. 

We  carry  out  implicit  specialization,  as  for  transactions,  by 
first  setting  up  the  appropriate  property  definition  to  identify  the 
new  script  and  then  associating  new  or  specialized  properties  with 
that  script.  The  following  property  definitions  accomplish  the  same 
specialization  of  AC  QUIRE-TICKET  as  the  ACQUIF.E-CHA  RTER-TIC  KET 
script  given  above. 

transition  good- date  on 

~  (CHARTER-RES-NUM, TRAVEL-AGENT) . .acquire-ticket  is 
conditions 

good-date?:  date-dif f erence  (d ate)  >  60; 

trans ition  bad- char ter- da te  on 

(CHARTER-RES-NUM, TRAVEL-AGENT) . .acquire-ticket  is 
from  f 1 ;  received-date; 
to  tl:  waiting-date; 
conditions 

bad-date?:  date-dif ference (date)  <=  60; 
actions 

bad-date:  date-status  < —  'bad'; 

tell-user:  s-inform (travel-agent,  code,  date-status); 
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ask-new-date;  s-reguest ftravel- agent. code .  date); 

transition  cancelling-cha rter  on 

(CHARTER-RES-NUM, TRAVEL-AGENT)  . . acquire- ticket  is 
from  f 1 s  waiting- paymen t ; 
to  tl :  reservation-cancelled; 
conditions 

cancel?;  ( (date-difference (da te)  <=  60)  or 
(reservation-cancelled  =  true)) ; 

actions 

cancel-reservation;  cancel-seat  (p, (f#,date)  .flight)  ; 
ticket-not-issued ;  ticket-issued  < —  false  ; 
tell-user:  s- inform (travel- agent,  code .  ticket-issued); 

transition  paying-now  on 

(CH ART ER -RES- NUM , TRAVEL- A GENT) . . a cquire-ticket  is 
conditions 

full- pay ment?  ;  (payment-amt  =  {f#,  date)  .  flight. ticket-cost)  ; 

transition  ref und- impossible  on 

(CH ARTER-RES-NUM ,TR A VEL-AGENT) . .acguire-ticket  is 
from  f 1 ;  ticket-purchase; 
to  tl;  successful-purchase; 
conditions 

a fter-60-days? ;  date-difference  (date)  <=  60; 


While  the  two  specialization  technigues  are  equivalent  in  that 
they  both  accomplish  the  same  task,  implicit  specialization  has  one 
important  advantage  over  explicit  specialization.  To  acquire  an 
airline  ticket  on  a  charter  flight  with  the  explicit  specialization 
we  would  have  to  explicitly  call  the  ACQUIRE-CHAPTER-TIC KET  script 
but  with  the  implicit  specialization  we  would  just  call  the 
ACQUIRE-TICKET  script  with  the  first  parameter,  reservation#,  being 
an  instance  of  CHARTER-RES-NUM  (versus  being  an  instance  of  just 
RES-NUM) .  Thus  implicit  specialization  causes  the  appropriate 
specialized  or  new  properties  to  be  automatically  associated  or  not 
associated  with  a  script  definition  depending  on  the  classes  of  the 
script*s  parameter  values. 


2.4  Conclusion 
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As  noted  by  Zisman  [  Zisman  77],  the  complete  understanding  of 
an  APN  requires  the  viewing  of  two  separate  representations.  First, 
the  APN  representation  gives  us  an  overview  of  scripts  without  the 
details  associated  with  their  transitions.  Second,  the  script  code 
gives  us  the  details  of  the  transitions  without  the  overall  view 
supplied  by  an  APN  representation.  This  has  the  advantage  that  the 
programmer  can  design  the  appropriate  Petri  net  for  a  situation 
without  concerning  himself  with  the  details  cf  each  transition. 
Once  this  has  been  done,  he  can  write  the  appropriate 
condition-action  pairs  that  comprise  the  transitions  without 
concerning  himself  with  the  overall  Petri  net. 

The  ACQUIRE-TICKET  script  example  (and  its  specialization)  show 
some  of  the  power  of  APNs  for  modelling  dialogue  flow.  The  dialogue 
for  acquiring  the  reservation  data  allows  the  user  to  input  the  data 
in  any  order.  Input  of  an  incorrect  date  causes  the  script  to 
engage  in  dialogue  with  the  user  in  an  attempt  to  obtain  a  correct 
one.  Once  a  reservation  has  been  made  the  APN  allows  very  flexible 
dialogue  for  purchasing  the  ticket  and/or  cancelling  the 
reservation.  The  use  of  APNs  for  modelling  dialogue  flow  means 
nonsense  events,  such  as  cancelling  a  reservation  before  it  has  been 
made,  cannot  occur.  In  this  way,  APNs  are  used  to  provide  the 
context  within  which  dialogues  take  place. 

The  dialogue  allowed  in  the  above  script  example,  while 
powerful  in  many  respects,  is  still  a  bit  primitive.  For  example, 
while  a  simple  semantic  check  was  made  on  the  input  date  (with  a 
simple  dialogue  to  correct  invalid  dates). 


extensive  semantic 
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checking  of  all  input  reservation  data  (with  appropriate  dialogue  in 
the  case  of  erronous  data)  would  be  a  vast  improvement.  For 
instance,  once  the  flight's  number  and  date  have  been  input,  the 
script  should  check  if  such  a  flight  actually  exists;  if  it  doesn't 
than  a  dialogue  should  be  started  to  obtain  a  new  flight  number 
and/or  date.  Another  example  of  a  more  powerful  type  of  dialogue 
easily  modelled  using  APNs  is  verification  dialogue.  That  is,  once 
all  the  reservation  data  has  been  obtained  (and  has  passed  all 
required  semantic  tests)  the  data  should  be  echoed  before  the 
reservation  is  made  and  the  user  should  have  the  option  of  changing 
any  or  all  of  it.  If  no  changes  are  desired  the  reservation  would 
immediately  be  made.  However,  if  changes  are  desired  then  all 
changed  data  would  have  to  repass  the  appropriate  semantic  tests  and 
then  be  re-echoed  for  user  approval.  This  verification  process 
would  be  repeated  until  no  more  data  changes  are  made,  at  which  time 
the  reservation  would  immediately  be  made.  APN  structures  to 
support  these  types  of  dialogue,  as  well  as  many  others,  are 
presented  in  Chapters  4  and  5. 

The  fact  that  the  ACQUIR E-TICKET  script  and  its  specialization 
deviate  only  slightly  from  the  existing  syntax  and  semantics  of  the 
other  TAXIS  classes  supports  the  claim  made  earlier  in  Chapter  1 
that  scripts  and  transitions  have  been  successfully  incorporated 
into  TAXIS  as  just  two  of  many  metaclasses.  That  is,  the  basic 
framework  of  TAXIS  (i.e.  properties,  classes,  and  the  IS-A 
hierarchy)  have  been  successfully  used  to  represent  scripts. 
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Syntax  and  Informal  Semantics  of  TAXIS  Scripts 


3.  1  Syntax  Design  and  Notation 

Script  and  Transition  classes  are  incorporated  into  TAXIS  as 
just  two  of  many  built-in  metaclasses.  They  have  been  designed 
using  as  much  previously  defined  TAXIS  syntax  as  possible,  with  new 
syntax  introduced  only  where  necessary.  For  example,  script  classes 
have  parameter  list  and  locals  property  categories  as  do 
transactions  and  both  classes  have  the  same  exception  handling 
mechanism.  Also  transition  classes  have  actions  and  postregs 
(referred  to  as  results  in  [Wong  80])  property  categories  as  do 
transaction  classes.  Script  classes  are  like  variable  classes  in 
that  the  p-values  (i.e.  property  values)  of  their  local  variables 
can  be  accessed  (but  not  changed)  using  the  same  kind  of  notation. 
Furthermore,  the  same  type  of  stepwise  refinement  through 
specialisation  as  is  possible  with  ether  TAXIS  classes  is  possible 
with  script  and  transition  classes. 

To  make  coding  as  simple  as  possible,  TAXIS  scripts  are 
designed  to  correspond  directly  with  their  representative  APNs.  As 
such,  scripts  are  "transition  based"  in  that  transitions  make  up  the 
body  of  a  script.  Each  transition  can  be  compared  to  a  production 
rule  and,  in  this  light,  a  script  can  be  thought  of  as  a  structured 
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collection  of  such  production  rules. 

The  notation  used  to  express  the  syntactic  rules  is  the  same  as 
used  by  [Wong  80]  [Section  3.1c).  In  particular: 

1)  Nonterminals  are  represented  by  strings  of  English  words 
beginning  with  capital  letters. 

2)  Concatenation  is  represented  by  one  or  more  blanks.  It  has 
precedence  over  alternation  [represented  by  j)  although  parentheses 
can  be  used  to  override  this  precedence. 

3)  Zero  or  more  occurrences  of  a  construct  are  represented  by 
enclosure  of  the  construct  by  the  brackets  {  and  }. 

4)  Zero  or  one  occurrence  of  a  construct  is  represented  by 
enclosure  of  the  construct  by  the  brackets  [  and  ]. 

5)  One  or  more  occurrences  of  a  construct  are  represented  by 
C-list  where  C  is  the  construct.  C-list  is  equivalent  to 
C  {  C  }. 

6)  Special  symbols  are  as  in  [Wong  80]  with  special  symbols  for 
keywords  surrounded  by  single  quotes.  Additional  keywords,  needed 
for  scripts,  are  added  to  the  special  symbols  already  given. 

Additional-keywords  =  *  transition-list 1  | 

'from*  \  'to*  j  Conditions'  1  'transition'  ! 

»u-inform'  |  'u-informed'  j  'u-request'  |  'u-requested '  | 

' s- inform'  j  's-informed*  |  ' s- request'  j  ' s- requested '  1 
'ask'  |  'asked*  [  'give'  |  'giving'  |  'gave'  1 
'take*  1  'taking®  |  'took®  j  ®on®  |  'off*  | 

'instantiate*  j  'terminate'  ; 
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7)  Comments  in  TAXIS  are  delimited  by  /*  and  */  as  in  many 
ether  programming  languages. 

3. 2  Syntax  and  Semantics 

A  TAXIS  script  class  begins  with  the  word  SCRIPT -CLASS, 
followed  by  an  identifier  as  the  name  of  the  script,  then  an 
optional  list  of  script  classes  as  generalizations,  and  finally  the 
property  definitions  of  the  script  class.  Script  classes  have  three 
property  categories:  'parameter-list1,  'locals',  and 

' transition- list ' . 

Script-class-definition  =  SCRIPT-CLASS  Identifier 
[  'isa'  Identifier-list  ]  'with* 

[  Parameter-list-category  ] 

[  Local- variable-category  ] 

[  Transition-list-category  ] 

'end*  Identifier  ';'  ; 

3._2.J.  The  Parameter  List  Category 

The  parameter  list  category  is  syntactically  the  same  for 
scripts  as  it  is  for  transactions. 

Parameter-list-category  =  '  para  me  ter-  list ' 

Parameter-list-property  ; 

Parameter-list-property  =  Identifier  ('  Identifier-list  ')'  ; 

The  parameter  list  property  of  a  script  associates  a  name  (called  an 
attribute)  which,  by  convention  is  always  the  same  as  the  script's 
identifier,  to  a  list  of  identifiers  acting  as  the  script's 
parameters.  Thus  it  sets  up  a  definitional  property  whose  subjects 
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are  the  classes  of  the  parameters,  whose  attribute  is  the  script's 
name,  and  whose  value  is  the  script  definition.  Particular  values 
of  a  script's  parameters  define  a  factual  property  whose  value  is 
not  the  result  of  executing  the  script  (as  it  is  for  transactions) 
but,  rather,  a  current  instance  of  the  script  itself  (this  is  the 
same  as  for  variable  classes) .  Thus 

(RESERVATION#, TRAVEL-AGENT) . . acguire-ticket 
returns  the  script,  ACQUIRE-TICKET,  as  its  value  while 

(10628, joe- a gent) . acquire- ticket 

returns  the  instance  of  the  ACQUIRE-TICKET  script  uniquely 
identified  by  the  parameters,  10628  and  'joe-agent',  as  its  value. 
(If  such  a  script  instance  does  not  exist  the  value  nothing  is 
returned)  . 

A  script  must  have  at  least  one  parameter;  otherwise  no 
definitional  or  factual  properties  can  exist  for  that  script.  In 
this  case  neither  the  script  definition  nor  any  of  its  instances 
could  be  accessed  as  there  would  be  no  way  of  identifying  the 
script.  It  is  illegal  for  more  than  one  instance  of  a  script  to 
have  the  same  parameter  values;  this  ensures  that  each  script 
instance  is  uniquely  identified.  It  is  also  illegal  for  a  script 
instance  to  change  the  values  of  its  parameter  properties  during  its 
execution  as  this  changes  the  factual  property  uniquely  identifying 
that  instance.  This  same  kind  of  rule  also  applies  to  the  key 
properties  of  a  variable  class. 
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jL.2^2  The  Local  Variable  Category 

The  local  variable  category  is  specified  in  the  same  manner  for 
scripts  as  for  transactions. 

Local-variable-category  =  *  locals®  Attribute  {  Attribute  }  ; 

Attribute  =  Identi f ier- list  Class-name  *;*  ; 

Class-name  =  Identifier  | 

Class- name  (..|.)  Identifier  | 

(*  (*  Class-name-list  *)®  (..|.)  Identifier)  ; 

All  parameters  in  the  parameter  list  and  any  other  variables 
required  within  the  script  must  be  declared  in  the  local  variable 
list.  There  are  no  scope  rules,  in  the  ALGOL  60  or  LISP  sense,  for 

local  variables  between  scripts.  Of  course,  all  data  classes  are 

global  and  data  can  be  passed  between  scripts  as  arguments.  Data 
can  also  be  passed  between  script  instances  using  I/O  commands  (more 
on  this  later) . 

As  a  conseguence  of  the  fact  that  execution  instances  of 

scripts  can  exist  for  significant  periods  of  time,  a  local  variable 
can  be  declared  to  have  as  legal  values,  instances  of  other  scripts. 
Thus  the  local  variable  property 

ticket:  ACQUIRE- TICKET; 

or  equivalently 

ticket :  (RESERVATION  #,TRAV EL-A GENT)  . . acguire-tic ket ; 

means  that  the  variable,  ticket,  can  have  an  instance  of  the 

ACQUIRE-TICKET  script  as  its  value.  Thus  the  assignment 
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ticket  < —  (10628, joe-agent) .acguire-ticket; 

assigns  to  ticket  the  current  instance  of  the  ACQ DIR E-TICKET  script 
uniquely  identified  by  the  10628  and  joe-agent  arguments.  Now,  if 
we  wish  to  find  the  name  of  the  passenger  in  the  above  script 
instance,  we  can  write 

ticket. p. name 
which  is  equivalent  to 

(106  28, joe-agent) . acguire-ticket. p. name 

If  an  instance  of  ACQUIRE-TICKET  with  the  above  parameter  values 
does  not  exist  then  both  expressions  return  nothing.  However  if 
such  a  script  instance  does  exist,  but  the  p.name  property  is  as  yet 
undefined,  then  both  expressions  return  unknown :  otherwise  both 
expressions  return  the  p-value  of  p.name. 

We  can  use  the  variable  ticket  to  retrieve  Instances  of 
ACQUIRE-TICKET  that  satisfy  specific  conditions,  in  the  same  manner 
as  for  variable  classes.  For  example,  suppose  we  wish  to  inform  the 
travel  agent  ’joe-agent*  of  the  reservation  numbers,  names, 
addresses,  and  phone  numbers  of  all  passengers  on  flight  007  for 
January  8,  1980.  We  can  accomplish  this  by  the  following  statement: 

for  ticket  in  ACQUIRE-TICKET 
where  f  (ticket. f #  =  007) 

and  (ticket. date  =  08/01/80))  do 
s- in form  (joe-agent. code, ticket. reservation#, 
ticket. p. na  me, ticket. p. address, 
ticket. p. phone#) 
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The  state  variables  used  by  the  transitions  of  a  script  must  be 
declared  in  the  local  variable  category.  Each  state  variable  must 
be  declared  to  be  of  finitely  defined  class  STATE  which  is  defined 
as 


STAT  E := { | 'on' , 'off  * \ } ; 

To  specify  which  transitions  of  a  script  are  initially  enabled,  we 
must  initialize  the  appropriate  input  states  of  these  transitions  to 
have  the  value  ’on*.  All  other  uninitialized  state  variables  have 
the  default  value  unknown.  Assigning  the  value  'off*  to  a  state 
represents  removing  a  token  from  the  state  denoted  by  that  variable. 

Since  a  state  variable  can  only  have  values  of  *on*  or  ‘off* 
(or  unknown)  it  is  impossible  for  a  state  in  a  script  to  have  more 
than  one  token  in  it.  Thus,  assigning  the  value  'on'  to  a  state 
variable  which  already  has  that  value  represents  the  absorption  of 
that  token. 

Because  the  current  marking  of  a  script  can  be  found  by 
observing  the  values  of  the  state  variables,  we  can  overcome  one 
drawback  of  Petri  nets:  the  inability  to  model  the  NOT  condition. 
(For  example,  if  a  token  is  not  in  a  state  then  place  one  there). 

If  a  state  variable  has  the  value  unknown  then  it  has  never 
been  marked.  On  the  other  hand,  if  a  state  variable  has  the  value 
'off'  then  it  is  presently  unmarked  but  has  been  marked  in  the  past. 
Of  course,  a  state  variable  with  the  value  'on'  is  currently  marked. 
Since  a  script  instance  can  have  its  p-values  accessed  externally  by 
another  script  instance,  it  is  possible  for  a  script  instance  to 
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view  the  execution  history  of  another  script  instance  (and  perform 
some  actions  based  on  this  information,  if  desired). 

Note  that  in  a  script  enough  state  variables  must  be 
initialized  to  value  'on’  to  enable  at  least  one  transition; 
otherwise  execution  of  that  script  could  never  start. 

3.2.3  The  Transition  List  Category 

As  mentioned  earlier,  transitions  make  up  the  body  of  a  script. 
A  transition  list  consists  of  one  or  more  transitions  that 
correspond  directly  with  the  transitions  of  a  script's 
representative  APN. 

Transition-list-category  =  'transition-list' 

Transition-property- list  ; 

Transition-property  =  Identifier  Transition-class-definition 

'end*  Identifier  ; 

Transition-class-definition  = 

[  'from'  Input-state- proper ty  {  Input-state-property  }  ] 

[  'to'  Output-state-property  {  Output-state-property  }] 

[  'conditions'  Condition-property  {  Condition-property  }] 

[  'actions'  Action-property  {  Action- property  }] 

[  'postregs*  Condition-property  {  Condition-property  }] 

Input-state-property  =  Identifier  ' ; '  Identifier  ' ; '  ; 

Output-state-property  =  Identifier  ':'  Identifier  ';'  ; 

Condition-property  =  Identifier  ';'  Condition-expression 
[  'exc'  Identifier  Class-name 

'('  Simple-expression-list  ; 

Action- property  =  Identifier  *:'  Action-expression  *;'  ; 

The  condition  and  action  expressions  allowed  in  TAXIS  scripts  are 
covered  in  the  next  two  sections.  The  execution  of  a  transition 
occurs  in  a  similar  way  to  the  execution  of  a  production  rule.  That 
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is,  if  all  the  conditions  of  an  enabled  transition  are  true  then  its 
actions  are  performed,  its  postregs  conditions  checked,  and  it  is 
fired.  A  transition  is  enabled  if  all  the  input  state  variables 
specified  in  the  input  state  properties  have  the  values  of  'on'.  A 
transition  is  fired  by  assigning  the  value  of  'off*  to  all  state 
variables  in  the  input  state  properties  and  the  value  of  •on*  to  all 
state  variables  in  the  output  state  properties. 

Each  script  instance  has  an  interpreter  instance  associated 
with  it  which  executes  the  script  instance  by  continually  checking 
all  the  conditions  of  all  enabled  transitions  (i.e.  all  transitions 
in  the  active  transition  set).  When  a  set  of  conditions  belonging 
to  an  enabled  transition  are  all  found  to  be  true,  the  interpreter 
stops  condition  checking  and  executes  and  fires  that  transition. 
Condition  checking  is  then  restarted  on  the  new  active  transition 
set.  Thus  only  one  transition  can  be  executed  at  a  time.  This 
effectively  eliminates  concurrency  within  scripts  even  though  a 
script*s  APN  representation  might  show  otherwise.  The  interpreter 
also  maintains  data  about  local  variable  values  and  the  execution 
history  of  various  dialogue  and  I/O  commands  (see  next  two  sections 
for  details  about  these  commands)  . 

The  order  of  evaluation  of  the  transition  properties  of  a 
script  by  its  interpreter  is  as  follows.  First  all  sets  of 
conditions  of  transitions  in  the  active  transition  set  are  checked 
in  some  undefined  order.  When  the  script  is  first  created,  the 
active  transition  set  is  determined  from  the  state  variables  that 
have  been  initialized  to  have  values  of  on.  If  all  conditions  of  an 
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enabled  transition  are  found  to  be  true,  the  actions  associated  with 
that  transition  are  carried  out.  Once  all  actions  have  been 
executed,  the  transitions  postregs  conditions  are  checked.  After 
all  these  have  been  successfully  evaluated,  the  transition  is  fired. 
Condition  checking  of  all  transitions  in  the  new  active  transition 
set  starts  again.  This  execution  cycle  continues  until  either  the 
script  is  explicitly  terminated  by  a  terminate  command  [see  next 
section)  or  is  implicitly  terminated  by  an  empty  active  transition 
set. 

The  order  in  which  transitions  in  the  active  transition  set  are 
checked  should  not  be  important.  That  is,  if  two  sets  of  conditions 
belonging  to  two  enabled  transitions  are  all  true  simultaneously,  it 
should  not  matter  which  transition  is  executed.  If  it  does  matter, 
then  the  representative  APN  of  the  script  has  been  incorrectly 
designed.  If  a  transition  has  no  conditions  property  then  a 
condition  of  true  is  assumed.  If  a  transition  has  more  than  one 
conditions  property  then  all  must  be  true.  A  transition  can  have 
zero  or  more  actions  properties  associated  with  it.  The  order  of 
execution  of  several  actions  properties  is  sequential;  this  is 
because  the  evaluation  of  one  action  may  require  the  results  of 
previous  actions.  The  order  of  execution  of  postregs  properties  is 
also  sequential  [although  there  is  no  strict  requirement  for  this  as 
the  condition  expression  of  a  postregs  property  must  be  a  boolean 
expression  without  side  effects) . 

Transitions  are  similar  to  transactions  in  many  ways.  An 
enabled  transition  cannot  execute  its  actions  until  all  its 
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conditions  are  true  while  a  transaction  cannot  execute  its  actions 
until  all  its  preregs  properties  have  been  successfully  evaluated. 
Once  the  actions  of  either  a  transition  or  a  transaction  have  been 
executed,  both  classes  evaluate  their  postregs  properties  and  then 
terminate;  the  transition  by  firing  and  the  transaction  by 
returning  a  value  to  its  caller.  The  expressions  allowed  as 
preregs,  actions,  and  postregs  properties  of  a  transaction  are  a 
subset  of  the  expressions  allowed  as  conditions,  actions,  and 
postregs  properties  of  transitions  (with  transitions  also  having 
some  expressions  that  are  special  to  scripts) . 

Eoth  scripts  and  transactions  have  the  same  exception  handling 
mechanism  (see  Appendix  A  for  an  example  of  transaction  exception 
handling) .  A  failed  postreguisite  condition  in  a  script  causes  an 
instance  of  a  specified  exception  class  to  be  raised  (i.e.  created) 
and  execution  of  the  script  to  be  halted.  (If  an  exception  is  not 
specified,  an  execution  error  occurs).  The  caller  of  the  script 
specifies  the  exception  handler,  which  is  another  script  whose  only 
argument  is  the  exception  instance  raised.  Once  the  exception 
handler  has  resolved  the  circumstances  causing  the  exception  to  be 
raised  (i.e.  it  has  successfully  completed  its  execution), 
execution  of  the  suspended  script  is  resumed  at  the  next  executable 
statement. 

Some  important  differences  exist  between  scripts  and 
transactions.  If  a  transaction  calls  another  transaction,  the 
transaction  called  has  to  complete  its  task  before  the  calling 
transaction  continues  its  execution.  However  if  one  script  calls 
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another  script,  execution  in  the  calling  script  can  continue  in 
parallel  with  the  execution  of  the  called  script-  We  can,  however 
coordinate  the  execution  of  concurrently  running  script  instances  by 
using  I/O  commands  and  predicates  to  model  any  desired  coordination 
requirements.  (See  Chapter  4  for  an  example  of  this) . 

Another  important  difference  between  transactions  and  scripts 
is  that  scripts  "live”  longer.  That  is,  script  instances  can  be 
executing  for  long  periods  of  time.  For  example,  an  instance  of  the 
ACQUIRE-TICKET  script  can  realistically  run  for  2-3  months  or 
longer.  Transaction  instances,  on  the  other  hand,  are  created, 
executed,  and  destroyed  right  away.  (Note  that  this  is  why  we 
permit  the  accessing  of  the  p-values  of  a  script  but  not  the 
p-values  of  a  transaction) .  In  this  way,  scripts  are  more  like 
variable  classes  than  transactions. 

5. 2. 3* 1  The  Action  Expressions 

We  present  the  action  expressions  allowed  in  TAXIS  scripts 
first  (rather  then  the  condition  expressions)  as  many  of  the 
conditions  are  derived  from  the  allowed  actions. 

Action-expression  =  Expression-class  | 

Script-call-command  1 
Script- termination-command  | 

I/O-command  | 

Dialogue-command  ; 

Script-call-command  =  ’instantiate*  Class-name 
'  (*  Argument-list  ')  * 

{  *exc-handler *  Identifier  *for*  Class-name  *is* 

Class- name  }  ; 

Script- termination-command  =  'terminate*  Class-name 
'  ('  Argument-list  ')  '  ; 
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Argument  =  Identifier  |  Expression-class  ; 

I/O-command  =  Give-command  |  Take-command  ; 

Give-command  =  ’give(*  Class-name  {  1 , ’  Argument  }  •) '  ; 

Take-command  =  'take('  Class-name  {  Attribute  }  •)  1  ; 

Dialogue-command  =  Inform-command  | 

Reguest-command  J 
Ask-command  ; 

Inform-command  =  (  's-inform*  |  * u- inform*  ) 

'  {•  Class-name  '  , '  P-argument-list  •)•  ; 

Request-command  =  (  * s-reguest'  |  * u-reguest*  ) 

*  (*  Class-name  *,*  Argument-list  ’)  '  ; 

Ask-command  =  *  ask(*  Identifier  * , '  Expression-class-list  •)•  ; 

P-argument  =  Class-name  [  * < — *  Expression-class  ]  ; 

The  expression  classes  used  as  script  actions  are  all 
non-boolean  expressions  as  defined  in  [Wong  80].  One  important 
restriction,  placed  on  all  expressions  (this  includes  both  boolean 
and  non-boolean  expressions)  in  scripts  (and  also  in  transactions) , 
is  that  only  local  variable  properties  can  be  used  within  these 
expressions.  That  is,  we  cannot  use  the  attributes  of  any  of  the 
ether  properties  of  scripts  (or  transactions)  within  expressions  in 
a  script  (or  a  transaction) .  This  is  because  the  factual  properties 
of  the  other  properties  of  a  script  (or  a  transaction)  have 
non-meaningf ul  values. 

The  script  call  command  "instantiates”  or  creates  an  instance 
of  a  script.  The  arguments  passed  in  the  call  command  uniquely 
identify  the  newly  created  script  instance.  If  any  exceptions  are 
specified  for  any  postreguisite  conditions  in  the  instantiated 
script,  then  the  call  command  for  that  script  must  include  the 
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appropriate  exception  handler  specifications. 

The  script  termination  command  destroys  an  instance  of  the 
named  script  uniquely  identified  by  its  argument  list.  Any  script 
instance  "instantiated”  by  a  scripts  continues  its  own  execution 
independently  even  though  its  parent  script  may  have  terminated. 
This  is  another  reason  for  non- inheritance  of  local  variables  from  a 
parent  script  to  any  of  its  son  scripts.  It  is  legal  for  a  script 
to  terminate  itself  or  to  terminate  instances  of  other  scripts. 

The  I/O  commands  adopted  into  TAXIS  scripts  are  based  on 
Hoare* s  proposed  primitive  I/O  commands  for  communicating  sequential 
processes  [Hoare  78].  The  give  and  take  commands  are  used  to 
transfer  data  between  concurrently  running  script  instances.  Before 
these  I/O  commands  can  transfer  data  they  must  correspond  [Hoare 
78].  That  is,  the  take  command  in  the  script  instance  receiving 
data  must  specify  the  name  of  another  script,  the  give  command  of 
that  other  script  (i.e.  the  source  script)  must  specify  as  its 
destination  script,  the  name  of  the  first  script,  and  the  attributes 
of  the  take  command  must  match  the  arguments  of  the  give  command. 
For  example 

give  fal , 3. 5, 4)  and  take  fa 2, x :REAL, y: INTEGER) 

correspond  if  the  give  command  is  in  script  instance  a2  and  the  take 
command  is  in  script  instance  a  1 .  I/O  commands  that  correspond  are 
executed  simultaneously  and  the  value  (s)  in  the  give  command  are 
assigned  to  the  ident if ier  (s)  in  the  take  command.  A  give  command 
fails  (i.e.  produces  an  execution  error)  if,  in  attempting  to 
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execute  it,  the  destination  script  has  been  terminated  or  any  of  the 
values  it  is  to  transfer  are  undefined.  A  take  command  fails  if  in 
attempting  to  execute  it,  the  source  script  has  been  terminated. 
Since  give  and  take  commands  require  synchronization  before  they  can 
simultaneously  execute,  whenever  an  I/O  command  is  encountered,  it 
must  wait  for  a  corresponding  I/O  command  to  be  encountered  before 
any  data  transfer  occurs.  As  a  result  of  this,  corresponding  I/O 
commands  can  be  used  to  coordinate  the  execution  of  concurrently 
running  script  instances. 

The  dialogue  commands  are  primitive  acts  used  to  create 
dialogue  between  scripts  and  users.  The  u-inf  orm  and  s-inf  or  in 
commands  are  used  to  pass  data  to  the  script  or  the  user 
respectively.  Similarly  the  u-reauest  and  s-reguest  commands  are 
used  to  obtain  information  from  the  script  or  user  respectively. 
Thus,  the  prefix  "u"  or  "s"  indicates  whether  the  user  or  script  is 
executing  the  command.  Finally  scripts  can  request  the  user  to 
perform  some  action  by  using  the  ask  command. 

The  inform  and  reguest  commands  have  already  been  illustrated 
in  the  script  and  dialogue  example  given  in  Chapter  2.  As  mentioned 
previously,  a  u- inform  command  cannot  be  executed  unless  the 
appropriate  s-reguest  command  (s)  have  been  made  for  its  values 
(while  s- inform,  u- request,  and  s-reguest  commands  do  not  require 
any  previous  dialogue  command (s)  to  have  been  executed).  For 
example 

s-reguest  (joe-agent. code, date) 

must  have  been  executed  before  *  joe-agent*  can  u- inform  a  date.  If 
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he  were  to 

u-inf orm  ( (10628, joe-agent) - acquire-ticket , 
date  <--  'january  8,1980*) 

the  u-inf  orm  would  fail  as  the  date  is  not  of  class  DATE- VALUE.  The 
travel  agent  could,  however,  request  the  form  the  date  should  be  in 
by  executing 

u-reguest ( ( 1 0628 , joe-agent) . acquire- ticket, 

ACQUIRE-TICKET. . da te) 

which  would  return  the  definitional  p-value  of  date,  DATE-VALUE,  as 

its  value.  Now  the  travel  agent  can  correctly  execute 

u-inform ( (10628, joe-agent) . acguir e-ticket , 
date  <—  08/01/80) 

to  enter  the  date.  If  desired,  the  script  could  be  designed  to 
inform  the  travel  agent  of  the  date*s  class  while  asking  for  it  by 
executing 

s- in form  (joe-agent. code, ACQUIRE- TICKET. . date) 
which  would  pass  the  DATE-VALUE  class  definition  to  the  travel 
agent . 

The  first  argument  of  an  ask  command  must  identify  the  intended 
recipient  of  the  generated  dialogue.  The  other  arguments  must  be 
boolean  expressions  with  side  effects.  If  a  boolean  expression  is 
true  no  action  is  performed.  However,  if  it  is  false  the  expression 
is  passed  to  the  user  to  make  true.  For  example,  suppose  some 
script  reguires  the  travel  agent  *  joe-agent*  to  make  an  airline 
reservation  for  *  joe- passenger *  on  flight  007  for  January  8,  1980 

(as  in  chapter  2) .  The  following  ask  command  would  accomplish  this 

ask  (joe-agent. code. 

not  (get-object  x  in  RESERVATION 
where  (x. name=* joe-passenger* , 
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x. f light=007 , 

x. date=0 8/0 1/80) ) = nothing) 

If  the  above  boolean  expression  is  true  (i.e.  the  indicated 
reservation  has  been  made)  nothing  is  done.  But,  if  the  above 
boolean  expression  is  false  (i.e.  the  indicated  reservation  hasn*t 
been  made) ,  then  the  expression  is  passed  to  the  appropriate  travel 
agent  user.  The  travel  agent  can  respond  to  this  expression  in  many 
ways.  For  example,  he  could  instantiate  the  AC QUIF. E-TICKET  script 
or  he  could  simply  do  nothing.  Regardless  of  what  he  does,  the 
script  would  have  to  make  an  explicit  check  at  some  later  time  to 
see  if  the  requested  action  has  been  performed.  No  means  are 
provided  for  a  user  to  directly  perform  an  action.  This  is  so 
control  can  be  maintained  by  the  system  as  to  what  operations  can  be 
performed  on  the  database  (and  with  what  data).  For  example,  to 
insert  a  tuple  in  the  RESERVATION  relation  (thus  satisfying  the 
above  ask) ,  we  can  use  the  ACQUIRE- TICKET  script  (which,  in  turn, 
uses  the  RESERVE-SEAT  transaction  to  make  an  entry  into 
RESERVATION) .  We  cannot  directly  insert  the  tuple  with  an 
insert -object  operation.  Using  the  script  guarantees  that  the 
integrity  of  the  database  is  maintained. 

The  inform  and  reguest  commands  can  be  compared  to  the  give  and 
take  commands  in  that  one  could  imagine  a  ” user  script”  having  a 
corresponding  request  or  inform  for  each  script  inform  or  request. 
(In  fact,  a  s-reguest  command  must  have  been  executed  before  a 
u-inform  command  with  the  reguested  data  can  be  executed,  although 
no  synchronization  is  required).  Similarly  one  could  imagine  a 


command  in  the  "user  script”  corresponding  to  an  ask  command.  Thus, 
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when  a  script  "asks"  the  user  to  perform  some  action,  we  can  imagine 
the  user  expecting  to  be  asked  to  perform  this  type  of  action. 

3. 2. 3. 2  The  Condition  Expressions 

The  condition  expressions  allowed  in  TAXIS  scripts  are 
presented  below.  Note  that  many  of  the  predicates  given  here  are 
derived  directly  from  the  action  expressions. 

Condition-expression  =  Expression-class  1 

I/O-predicate  1 
Dialogue-predicate  ; 

I/O-predicate  =  Input-predicate  1  Output-predicate  ; 

Input-predicate  =  {'giving'  |  'gave') 

'('  Class-name  {  ' , '  Attribute  }  ')'  ; 

Out  put- predicate  =  {'taking'  |  'took') 

'{'  Class-name  {  ' , '  Argument  }  ')'  ; 

Dialogue-predicate  =  Informed-predicate  1 

Reguested- predicate  | 

Asked- predicate  ; 

Informed-predicate  =  { ' s-inf ormed '  |  ' u-inf ormed') 

'(»  Class-name  ','  P-argument- list  ')*  ; 

Reguested-predicate  =  { 's- reguested  '  1  ' u-reguested ') 

'('  Class-name  Attribute-list  ')'  ; 

Asked-predicate  =  ' asked  ('  Class-name  '  ,' 

Expression-class-list  ')  '  ; 

Expression  classes  allowed  as  conditions  in  TAXIS  scripts  are 
expressions  as  defined  in  [Wong  80]. 

To  avoid  failure  of  I/O  commands  and  to  obtain  information 
about  the  past  and  present  state  of  a  script's  I/O  communication 
history  we  have  four  I/O  predicates.  A  giving  or  taking  predicate 
returns  true  if,  upon  execution,  a  matching  give  or  take  command  is 
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waiting  in  the  named  script;  otherwise  false  is  returned.  In  a 
similar  fashion,  a  gave  or  took  predicate  will  return  true  if,  upon 
execution,  a  matching  c[iye  or  take  command  has  been  successfully 
executed  in  the  named  script;  otherwise  false  is  returned. 

As  an  example  of  I/O  predicates  consider  possible  communication 
between  two  script  instances,  scriptl  and  script2.  If  script  1  has  a 

give  (script 2, fl-pt) 

command  waiting  (where  fl-pt  is  a  real  number)  then  execution  of 
giving  (script  1 ,num : REAL) 

in  script2  would  return  true,  whereas  execution  of 
giving  (scriptl , num ; INTEGER) 

in  script2  would  return  false.  To  actually  " give"  num  the  value  of 
fl-pt  a 

take  (script  1 ,num : REAL) 

command  must  be  executed  in  script2.  After  this  I/O  communication 
has  occurred,  both  a 

gave  (scriptl ,num : PEAL) 

in  script2  and  a 

took  (script2 , fl-pt) 

in  scriptl  will  have  true  as  their  values.  Alternatively,  if 
script2  has  a 
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take  (script  1 , mint : REAL) 
waiting  then  execution  of 
taking  (script2, f 1-pt) 

in  scriptl  would  return  true  whereas  execution  of 
taking  (script2, int) 

in  scriptl  (where  int  is  a  integer  variable)  would  return  false.  Of 
course,  execution  of 

give  (script2 , f 1- pt) 

in  scriptl  would  successfully  complete  the  I/O  communication. 

To  gain  information  about  the  past  dialogue  history  of  a  script 
we  have  five  dialogue  predicates.  An  uninformed  predicate  returns 
true  or  false  depending  on  whether  one  or  more  u-inform  commands 
have  supplied  values  to  its  argument  list.  For  example,  if  the 
u-inform  commands 

u-inform  (  (10628, joe-agent) . acquire-ticket, 
f#< — 007,p. name< — ' joe- passenger ' ) 


and 


u-inform  (  (10628, joe- a gent) .acquire-ticket, 
date<  —  08/01/80) 


have  been  executed  then 
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u-in  formed (joe- agent . code, f # ,p. name/ date) 

returns  true  as  its  value  while 

uninformed  ( joe- a gent. code, f# ,p.name, p. address) 

would  return  false  as  its  value  (assuming  a  u-inf orm  command  for 
p. address  has  not  been  executed). 

Similarly  the  other  four  predicates,  s- in formed .  u-reg uested, 
s-requested.  and  asked  return  true  or  false  depending  on  whether  the 
appropriate  s-inf orm.  u-reguest .  s- request,  or  ask  commands  have 
been  executed.  The  asked  predicate  does  not  check  to  see  if  its 
boolean  expression  arguments  have  been  made  true  or  not  (an  explicit 
check  has  to  be  made  in  this  regard) ,  but  only  if  a  dialogue  act  has 
been  performed  for  each  boolean  expression  argument.  If  a  boolean 
expression  had  initially  been  true  in  an  ask  command  (i.e.  no 
dialogue  act  was  performed),  then  a  matching  asked  predicate,  when 
evaluated,  would  return  false. 

3. 3  The  IS-A  Constraints  Governing  Specialization  of  TAXIS  Scripts 

Because  the  dominant  design  principle  offered  by  TAXIS  is 
stepwise  refinement  through  specialization,  TAXIS  script  and 
transition  classes,  as  all  other  TAXIS  classes,  can  be  specialized 
provided  these  specializations  satify  appropriate  IS-A  constraints. 
For  a  script  A  to  be  a  specialization  of  a  script  B,  A  must  have  at 
least  the  properties  of  B.  A  can  also  have  new  properties  or 
properties  that  are  specializations  of  existing  properties  of  B. 
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The  IS-A  constraints  governing  the  specializations  that  can  be 
made  for  each  of  the  three  property  categories  of  a  script  are  as 
follows: 

1)  The  parameter  list  of  a  script  can  be  specialized  in  exactly 
the  same  way  as  the  parameter  list  of  a  transaction.  That  is,  the 
class  of  each  parameter  can  be  specialized.  New  parameters  cannot 
be  added  as  this  would  introduce  a  new  script  property  definition. 
The  class  of  each  specialized  parameter  in  a  script  must  be  IS-A  the 
class  of  the  corresponding  parameter  in  that  script* s  immediate 
generalizations. 

2)  The  local  declaractions  of  a  script  can  be  specialized  in 
exactly  the  same  ways  as  the  local  declarations  of  a  transaction. 
That  is,  local  variables  can  have  their  classes  specialized  or  new 
local  variables  can  be  added.  Local  variables  representing  states 
(which  are  of  class  STATE)  can  be  specialized  by  restricting  their 
values  to  either  *on*  or  ’off*.  New  state  variables  can,  of  course, 
be  added.  Any  new  state  variables  can  be  appropriately  initialized 
so  that  the  specialized  script  has  an  initial  marking  that  is  a 
superset  of  the  initial  marking  of  its  immediate  generalizations. 

3)  The  transition  list  of  a  script  can  be  specialized  by  adding 
new  transitions  or  by  specializing  existing  ones.  If  new 
transitions  are  added  to  a  script  then  their  attributes  must  be 
unique  within  that  script.  Existing  transitions  can  be  specialized 
in  the  following  manner: 
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-  New  input  or  output  state  properties  can  be  added  to  a 
transition  but  no  existing  input  or  output  state  properties  can  be 
removed. 

-  One  or  more  new  conditions,  actions,  or  postregs  properties 
can  be  added  to  the  specialized  script.  Each  of  the  new  conditions, 
actions,  or  postregs  property  is  placed  at  the  end  of  the  inherited 
conditions,  actions,  or  postregs  properties  respectively  (this  has 
significance  only  for  a  new  actions  property) .  To  insert  a  new 
actions  property  between  two  inherited  actions  properties  we  must 
specify  the  attributes  of  the  two  inherited  properties  (without 
their  p-values)  with  the  attribute  and  p-value  of  the  new  actions 
property  inserted  in  between  the  two  inherited  property  attributes. 
(Note  that  the  order  of  inherited  properties  cannot  be  changed) . 
For  example: 

transition  trans 

on  /*  script  definition  property  */  is 
actions 

Pis 

p3:  a3; 

p2: 

inserts  action  "a3"  in  between  inherited  actions  "al"  and  "a2" 
(denoted  by  their  attributes  pi  and  p2  respectively)  into  the 
specialized  '•trans"  transition. 

-  One  or  more  existing  conditions,  actions,  or  postregs 
properties  can  be  specialized.  The  attribute  of  a  specialized 
property  must  be  the  same  as  the  attribute  of  the  more  general 
property  and  the  specialized  p-value  must  be  IS-A  the  more  general 
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p-value. 


-  If  a  new  postregs  property  is  added  or  an  existing  one  is 
specialized  then  the  appropriate  exception  classes  and  exception 
handlers  must  be  defined  or  specialized.  Also  all  instantiate 
commands  for  the  script  with  the  new  or  specialized  postregs 
property  must  be  specialized  to  include  the  appropriate  exception 
handling  specifications  {if  any) . 

Because  an  IS-A  hierarchy  does  not  have  to  be  a  tree,  it  is 
possible  for  a  script  class  (or  other  classes,  for  that  matter)  to 
have  two  or  more  parent  classes  (i.e.  a  class  can  be  IS-A  more  than 
one  class) .  In  this  case,  if  some  property  exists  in  two  or  more 
parent  classes  with  the  same  attribute  then  their  p-value s  must  be 
organized  in  an  IS-A  hierarchy.  In  such  a  case,  a  son  class  would 
inherit  the  most  specialized  property  in  the  IS-A  hierarchy  from  its 
parent  classes. 

There  are  two  ways  of  specializing  a  TAXIS  script:  explicit 
specialization  and  implicit  specialization.  Both  types  of 
specialization  are  carried  out  in  the  same  manner  as  explicit  and 
implicit  specialization  of  transactions  is  carried  out  (see  Appendix 
A  for  an  illustration  of  the  two  ways  of  specializing  a 
transaction).  These  two  specialization  techniques  have  also  been 
illustrated  in  Chapter  2  for  scripts.  Implicit  specialization  is 
the  best  method  of  specialization  as  new  or  specialized  properties 
are  associated  or  not  associated  automatically  with  a  script 
definition  depending  on  the  classes  of  the  subjects  of  the 
definitional  property  connecting  the  new  or  specialized  properties 
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to  a  more  general  script.  Explicit  specialization  requires  explicit 
calls  to  the  desired  script. 

Explicit  specialization  of  a  script  is  carried  out  in  the 

following  manner. 

1)  The  specialized  script  is  declared  to  be  IS-A  a  more  general 
script.  The  new  specialized  script  is  coded  according  to  the  syntax 
rules  for  a  script. 

2)  New  or  specialized  properties  are  specified  as  in  the  more 
general  script. 

3)  Any  property  being  inherited  need  not  be  specified  in  the 
specialized  script. 

Implicit  specialization  of  a  script  is  accomplished  in  the 

following  manner. 

1)  A  definitional  property  identifying  the  script  is  set  up  (in 
the  same  way  as  for  transactions) .  One  or  more  of  the  subjects  can 
have  their  classes  specialized  (thus  setting  up  a  definitional 
property  identifying  the  specialized  script). 

2)  New  or  specialized  properties  are  added  to  the  definitional 
property.  In  this  way,  a  list  of  properties  is  associated  with 
specialized  script  definition.  The  syntax  for  setting  up  property 
definitions  is  given  in  [Wong  80]  and  illustrated  in  Chapters  2  and 


4  of  this  thesis 
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3.4  Program  Design  Methodology 

The  design  methodology  of  IIS  programs  written  in  TAXIS  (as 
specified  in  [Wong  80]  and  extended  here  to  include  scripts)  is 
based  on  the  concept  of  specialization.  First,  the  most  general 
level  of  an  IIS  program  is  specified  in  the  following  order: 

1)  the  data  classes 

2)  the  transactions  that  operate  on  these  data  classes 

3)  the  exception  classes  needed  in  the  transaction  classes  for 
failure  of  preregs  or  postregs  properties 

4)  the  transaction  exception  handlers  that  resolve  raised 
instances  of  these  exceptions 

5)  the  script  classes  that  build  transaction  calls  from 
dialogue  conducted  with  users 

6)  the  exception  classes  needed  in  the  script  classes  for 
failure  of  postregs  properties 

7)  the  script  exception  handlers  that  resolve  raised  instances 
of  these  exceptions 

Cnee  the  most  general  level  of  an  IIS  program  has  been  obtained,  a 
more  detailed  program  is  obtained  by  refining  the  existing  classes 
(or  introducing  new  classes)  in  the  same  order  as  for  the  most 
general  level.  This  refinement  is  carried  out  in  a  stepwise  manner 
until  the  desired  level  of  detail  is  obtained.  Note  that  after  each 
level  of  specialization  a  complete  working  TAXIS  program  is 
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available  for  the  programmer  to  run.  The  specialization  of  TAXIS 
classes  is  not  ad  hoc;  it  must  follov  certain  IS-A  constraints  that 
vary  depending  on  the  property  categories  being  specialized  (see 
last  section  of  this  Chapter  and  Appendix  A) . 

3_j_5  Collected  Syntax 

The  collected  syntax  for  script  and  transition  classes  is 
presented  here. 


Script-class- definition  =  SCRIPT-CLASS  Identifier 
[  *isa*  Identifier-list  ]  'with* 

[  Parameter-list-category  ] 

[  Local-variable-category  ] 

[  Transition-list-category  ] 

'end1  Identifier  •;*  ; 


Parameter-list-category  =  ‘parameter-list* 
Parameter-list- property  *;*  ; 


Parameter-list-property  =  Identifier  *(:*  Identifier-list  •)*  ; 

Local-variable-category  =  ‘locals*  Attribute  {  Attribute  }  ; 
Attribute  =  Identifier-list  ';*  Class-name  *;’  ; 


Class-name  =  Identifier  | 

(Class-name  (,.|.)  Identifier)  J 

(*(•  Class-name- list  *)•  (..|.)  Idenfitier)  ; 


Transition-list-category  =  ‘transit  ion- list  * 
Transition-property-list  ; 


Transition-property  =  Identifier  *:*  Transition-class-definition 
‘end*  Identifier  •;*  ; 


Transition-class-definition  = 

[  ‘from*  Input- state- property  {  Input-state-property  }] 
[  ‘to*  Output-state-property  {  Out put-state- property  }] 


SYNTAX  AND  INFORMAL  SEMANTICS  OF  TAXIS  SCRIPTS 


Page  66 


CHAPTER  3 


[  •conditions’  Condition-property  £  Condition-property  }] 
[  •actions*  Action- property  {  Action-property  }] 

[  ’postregs*  Condition- property  £  Condition-property  }] 


Input-state-property  =  Identifier  *:’  Identifier  •;•  ; 


Cutput-state-property  =  Identifier  *:•  Identifier  •;«  ; 


Condition-property  =  Identifier  *:•  Condition-expression 
[  ’exc*  Identifier  Class-name 

»{*  Simple-expression-list  *) • ]  *;•  ; 


Action-property  =  Identifier  *:•  Action-expression  •;•  ; 


Action-expression  =  Expression-class  1 

Script-ca 11-coromand  | 
Script-termination-command  ] 
I /O-command  | 
Dialogue-command  ; 


Script-call-command  =  ’instantiate*  Class-name 
*(•  Argument-list  ’)  *  ; 

£  *exc-handler *  Identifier  *for*  Class-name  *is* 
Class-name  }  ; 


Script-termination-command  =  ’terminate*  Class-name 
’(*  Argument-list  •)’  ; 

Agrument  =  Identifier  |  Expression-class  ; 

I/O-command  =  Give-command  |  Take-command  ; 

Give-command  =  ’give(*  Class- name  £  ’,*  Argument  }  ’) •  ; 

Take-command  =  *take(*  Class-name  £  *,'  Attribute  }  *)*  ; 

Dialogue-command  =  Inform-command  | 

Reguest-command  | 

Ask-command  ; 

Inform-command  =  (  *s-inform*  j  * u- inform’  ) 
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* (*  Class-name  ' , '  P-argument-list  *)•  ; 

Eeguest-command  =  (  's-reguest*  |  * u- request*  ) 

'  (*  Class- name  '  ,  '  Argument- list  ')  •  ; 

Ask-command  =  »ask(*  Identifier  Expression-class-list  *) *  ; 

P-argument  =  Class-name  [  '<--'  Expression-class  ]  ; 

Condition-expression  =  Expression-class  | 

I/O-predicate  J 
Dialogue-predicate  ; 

I/O-predicate  =  Input-predicate  \  Output-predicate  ; 


Input-predicate  =  ('giving'  |  ’gave*) 

'  ('  Class-name  {  Attribute  }  *)  *  ; 


Output-predicate  =  ['taking*  |  'took') 

Class-name  {  Argument  }  •)'  ; 


Dialogue-predicate  =  Informed-predicate  1 

Reguested-predicate  1 
Asked-predicat e  ; 


Informed- predicate  =  ( ' s-informed '  1  • u-inf ormed ' ) 
'('  Class-name  P-agrument-list  ')'  ; 


Reguested-predicate  =  { 's-reguested  •  1  'u-reguested' ) 
•  { •  Class-name  ' , '  Attribute-list  *)'  ; 


Asked-predicate  =  'asked  ('  Class- name  ' , ' 

Expression-class-list  •) '  ; 
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Journal  Editing  Scripts 


4. 1  Another  Script  Example 

The  script  example  presented  in  this  chapter  serves  two 
purposes.  Eirst  it  gives  a  practical  illustration  of  how 
concurrently  running  script  instances  communicate  with  and 
coordinate  each  other  and,  second,  it  shows  how  exceptions  and 
exception  handlers  are  specified  for  scripts.  The  example  is  based 
on  a  modified  version  of  Zisman's  journal  editing  procedure  as 
outlined  in  Chapter  6  of  [Zisman  77].  Two  scripts  are  used  to  model 
this  procedure;  one  for  an  editor's  actions  and  one  for  a  referee's 
actions. 

The  APN  for  the  editor  script,  EDITOR-NET,  is  shown  in  figure 
4-A.  Once  a  paper  arrives,  the  editor  must  designate  one  or  more 
referees.  Each  week  that  he  fails  to  do  so  will  cause  a  reminder  to 
be  sent  to  him.  Once  the  referees  have  been  designated,  an  instance 
of  the  referee  script  is  created  for  each  referee.  If  one  or  more 
of  the  referees  should  refuse  to  review  the  paper  the  editor  is 
required  to  find  replacements.  Each  time  a  week  passes  in  which  the 
editor  hasn't  yet  designated  new  referees  to  replace  any  refusing 
referees  results  in  a  reminder  to  this  effect  being  sent  to  the 
editor.  Referee  script  instances  are  created  for  all  new  referees. 


Page  68A 


EDITOR-NET  FIGURE  4-A 


JOURNAL  EDITING  SYSTEM 


Page  69 


CHAPTER  4 

Cnee  all  proposed  referees  have  agreed  to  review  the  paper  the 
editor  waits  for  their  reports.  After  the  editor  has  received  all 
these  reports  he  must  make  his  decision  within  two  weeks;  otherwise 
he  receives  a  reminder  for  his  overdue  decision  every  two  weeks 
until  he  has  made  it.  If,  on  the  one  hand,  the  editor's  decision 
calls  for  a  revision  of  the  paper,  then  the  author  is  informed  of 
this  and  the  editor  awaits  the  revision.  Once  the  revised  paper  is 
received,  it  is  passed  to  each  of  the  referees  and  their  new  reports 
are  waited  for.  Once  the  editor  receives  these  reports  he  must 
again  make  a  decision  regarding  the  suitability  of  the  paper  for 
publication.  If,  on  the  other  hand,  the  editor's  decision  is  to 
accept  or  to  reject  then  the  author  is  informed  of  the  decision  and 
the  editor  and  referee  script  instances  are  terminated.  At  any  time 
after  the  editor  receives  a  paper  right  up  until  the  time  the  editor 
has  made  a  decision  of  either  accept  or  reject,  the  author  has  the 
option  to  withdraw  his  paper,  in  which  case  the  editor  and  referee 
script  instances  are  terminated. 

The  APN  for  the  referee  script,  REFEREE-NET,  is  shown  in  figure 
4-B.  Once  an  instance  of  the  referee  script  has  been  created  for  a 
proposed  referee,  the  referee  is  asked  for  his  consent.  If  his 
reply  is  no,  then  this  fact  is  communicated  to  the  editor  script  and 
the  referee  script  instance  is  terminated.  Each  two  week  period 
that  passes  with  no  reply  from  the  proposed  referee  results  in  a 
reminder  being  sent  to  that  referee.  To  prevent  reminders  from 
being  sent  to  a  proposed  referee  for  an  indefinite  period  of  time  an 
exception,  NO- REF-REPLY,  is  raised  after  the  third  reminder  has  been 
sent.  A  script  exception  handler,  REF-DOSEN 'T-ANSWER ,  which  has  the 
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raised  instance  of  NO-REF-REPLY  as  its  only  parameter,  is  expected 
resolve  this  situation.  If  the  proposed  referee's  reply  is  yes  then 
his  report  is  awaited.  Again,  each  two  week  period  that  passes 
without  the  editor  having  received  the  referee's  report  causes  a 
reminder  to  be  sent  to  that  referee.  And  again,  to  prevent 
reminders  from  being  sent  to  the  referee  for  an  indifinite  period  of 
time,  an  exception,  REPORT-LATE,  is  raised  after  the  third  reminder 
has  been  sent.  A  script  exception  handler,  REPOpT-NOT-R ECEI VED,  is 
expected  to  resolve  this  situation.  Once  the  referee's  report  has 
been  received  and  this  fact  has  been  communicated  to  the  editor 
script,  the  referee  script  waits  for  the  possibility  that  the 
editor's  decision  may  be  to  revise  (in  which  case  a  revised  paper 
should  be  forthcoming).  If  the  editor's  decision  is  to  accept  or  to 
reject  then  the  editor  script  terminates  all  instances  of  the 
referee  script  as  well  as  itself. 

The  program  design  methodology  outlined  in  Chapter  3  dictates 
that  we  first  design  the  data  classes  needed.  The  more  interesting 
of  these  are  presented  below. 

VARIABLE-CLASS  COMPUTER- SCIENTIST  isa  PERSON  with 
keys 

computer-scientist:  (name, address) ; 
characteristics 

academic-background :  ACADEMIC-DATA ; 

professional-background :  PROFESSIONAL-DATA; 

end  COMPUTER-SCIENTIST; 


VARI AELE-CLASS  NONUSER  with 
keys 

nonuser:  (name, address)  ; 
characteristics 

name:  NONUSER-PERSON-VALUE; 
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address :  NON  USER-ADDRESS-VALUE ; 
attributes 

code:  NONUSER-CODE; 
terminal-on?:  BOOLEAN; 
end  NONUSER; 


VARIABLE-CLASS  USER  with 
keys 

user:  (name, address) ; 
characteristics 

name!  USER-PERSON-VALUE; 
address:  USER-ADDRESS-VALUE; 
at  tributes 

code:  USER-CODE; 
logged-on?:  BOOLEAN; 
end  USER; 


VARIABLE-CLASS  AUTHOR  isa  COMPUTER-SCIENTIST , NONUSER  wit  h 
keys 

author:  (name, address) ; 
end  AUTHOR; 


VARIABLE-CLASS  REFEREE  is^  COM PUTER-SCIENTIST, NONUSER  with 
keys 

referee:  (name, address)  ; 
end  REFEREE; 


VARIABLE-CLASS  EDITOR  isa  COMPUTER-SCIENTIST , USER  with 
keys 

editor:  (name , address) ; 
end  EDITOR; 


VARIABLE-CLASS  PAPER  with 
keys 

paper:  (author, title)  ; 
characteristics 
author:  AUTHOR; 
title:  TITLE; 
text:  TEXT; 
end  PAPER; 


VARIABLE-CLASS  JOURNAL  with 
ke^s 
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journal:  (journal-name)  ; 
characteristics 

journal-name:  JOURNAL-NAME; 
attributes 

editor:  EDITOR; 
end  JOURNAL; 


VARI AELE-CLASS  REFLIST  with 
keys 

reflist:  (journal, paper , referee) ; 
characteristics 
journal;  JOURNAL; 
paper:  PAPER; 
referee:  REFEREE; 
end  REFLIST; 


The  COMPUTER-SCIENTIST  relation  contains  data  about  the 
academic  and  professional  background  of  people  who  are  computer 
scientists.  Since  COMPUTER-SCIENTIST  is  declared  to  be  IS-A  PERSON 
(with  PERSON  as  specified  in  Chapter  2) ,  it  inherits  all  the 
properties  of  PERSON.  The  AUTHOR  and  REFEREE  relations  are  both 
declared  to  be  IS-A  COMPUTER- SCIENTIST  and  NONUSER.  That  is,  AUTHOR 
and  REFEREE  inherit  the  most  specialized  properties  of  both 
COMPUTER- SCIENTIST  and  NONUSER.  The  EDITOR  relation,  on  the  other 
hand,  is  declared  to  be  IS-A  COMPUTER-SCIENTIST  and  USER  (with  the 
USER  relation,  as  given  in  Chapter  2,  changed  here  to  not  be  IS-A 
EERSON) .  The  distinction  between  a  user  and  a  nonuser  is  that  a 
user  has  direct  access  to  the  system  while  a  nonuser  only  has 
indirect  access  to  the  system.  Thus  s-inf orm  and  s-reguest  commands 


to  the  editor  are  transmitted  directly  to  the  terminal  the  editor  is 


logged  on. 

Similiarly 

u- inf orm 

and 

u-reauest 

commands 

from  the 

editor  are 

directly 

executed 

on 

the  terminal  by  him. 

H  owever , 

s-inform  and 

s-reguest 

commands 

to 

an  author 

or  a  referee  are 
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transmitted  directly  to  a  specific  terminal  (say  a  printer)  where 
letters  or  postcards  are  generated  and  delivered  by  the  postal 
system.  Similarly  u-inf orm  and  u-r eguest  commands  from  an  author  or 
a  referee  would  be  received  as  letters  or  postcards  and  entered  into 
the  system  by  the  editor  or  a  secretary. 

The  PAPER  relation  contains  data  about  papers  submitted  for 
publication;  in  particular,  the  author  and  title  data  and  the 
actual  text  of  these  papers.  Journal  name  and  editor  data  is 
maintained  in  the  JOURNAL  relation.  A  list  of  referees  reviewing 
papers  is  kept  in  the  REFLIST  relation.  To  keep  things  conceptually 
simple  the  editor,  author,  and  referee  data  in  the  above  relations 
are  of  classes  EDITOR,  AUTHOR,  and  REFEREE  respectively.  However, 
it  would  be  more  efficient  space-wise  to  store  just  the  keys  of 
these  classes,  thus  keeping  duplicated  data  to  a  minimum. 

Since  no  transaction  classes  are  needed  for  this  IIS  (and,  as  a 
result,  no  exception  classes  or  exception  handling  transaction 
classes)  the  program  design  methodology  (in  Chapter  3)  requires  us 
next  to  give  the  necessary  script  definitions.  But,  before  we 
specify  the  two  required  scripts,  EDITOR-NET  and  REFEREE-NET,  we 
give  some  comments  to  enhance  their  readability. 

Corresponding  give  and  take  commands  are  used  to  inform  the 
editor  script  if  a  referee  agrees  or  refuses  to  review  a  paper,  to 
inform  the  editor  script  if  a  referee  has  completed  his  report,  and 
to  inform  the  referee  script  if  a  revised  paper  must  be  reviewed. 
The  script  that  executes  the  ta ke  command  of  a  corresponding 


give/take  pair  uses  a  giving  predicate  to  check  if  a  give  command  is 
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waiting  to  execute,  in  which  case  a  corresponding  take  command  is 
executed.  The  use  of  giving  predicates  prevents  both  scripts  from 
having  deadlock  or  lockout  problems. 

The  ask  command  is  used  to  "ask”  the  editor  to  supply  some 
referee  names.  That  is,  a  false  condition  (that  there  are  referees 
who  are  reviewing  the  author* s  paper)  is  presented  to  the  editor  to 
make  true.  He  does  this  by  executing  a  script  that  acquires  the 
appropriate  data  for  proposed  referees  from  the  editor  (checking  for 
semantic  correctness  of  the  data,  etc.)  and  inserts  this  data  into 
the  REFLIST  relation. 

The  two  scripts,  EDITOR-NET  and  REFEREE-NET  are  now  given: 


SCRIPT-CLASS  EDITOR-NET  with 


parameter- list 

editor-net:  (editor , paper , journal) ; 


locals 

editor:  EDITOR; 
paper:  PAPER; 
journal:  JOURNAL; 
author:  AUTHOR; 
ref:  REFLIST; 

new-refs-in,  all- ref- names-in  , paper-withdrawn ,  reports-in, 
revision-submitted,  paper-received,  reports-subraitted :  BOOLEAN; 
ref-time,  new-ref-time,  decision- time :  INTEGER; 
reply:  {1'no*,  *yes'|}; 

decision:  {|*revise*,  'accept*,  'reject'l}; 
waiting-paper  default  'on*,  waiting-ref-names, 
waiting-paper- withdrawn ,  waiting-ref-replies, 
waiting-new-ref-names,  waiting- reports,  waiting-decision, 
waiting-revision,  editor-finished :  STATE; 


transition- list 


paper-arnves: 
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from  f 1 :  waiting- pa  per ; 
to  tl:  waiting-ref-names; 

t2:  waiting-paper-withdrawn; 
actions 

set-author:  author  < —  pa  per.  author ; 
paper- received:  pa per- received  < —  true : 
tell-author:  s-inform  (author,  code , paper-received)  ; 
paper-withdrawn?:  s-reguest  (author . code, paper-wit hdrawn)  ; 
get-ref-names:  ask  (editor .code, not  nothing  = 

(get-object  ref  in  REFLIST 
where  ((ref. journal  =  journal) 
and  (ref . paper  =  paper)))); 
all-ref-names-submitted?:  s-reguest  (editor. code, 

all-ref-names-in) ; 

set-wait-ref-time :  ref-time  < —  current-time; 
end  paper-arrives; 


ref- names- late: 

from  fl:  waiting-ref-names; 
to  tl:  waiting-ref-names; 
conditions 

time-exceeded?:  (current-time  -  ref-time)  >  604800; 

/*  604800  seconds  =  1  week  */ 
all-refs-not-in?:  all-ref-names-in  =  unknown  or 

all-ref-names-in  =  false; 

actions 

ask-for-refs:  ask  (editor. code , not  nothing  = 

fget-ob iect  ref  in  REFLIST 
where  ( (ref . journal  =  journal) 
and  (ref .paper  =  paper))))  ; 
all-ref-names-submitted?:  s-reguest  (editor. code, 

all-ref-names-in)  ; 

reset-ref-time:  ref-time  <--  current-time; 
end  ref-names-late; 


have-referees : 

from  fl:  waiting-ref-names; 
to  tl:  waiting-ref-replies; 
conditions 

all-refs-in? :  all-ref-names-in 
at- least- one- ref? : 

(begin 

locals 

count:  INTEGER; 
actions 

al:  count  < —  0; 
a2:  for  ref  in  REFLIST 
where  (  (ref.  journal 
and  (ref .paper  = 
count  < —  count 


=  true ; 


=  journal) 
paper) ) do 
+  1; 


returns 

rtn:  (count  >  0)  ; 
end)  =  true; 
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actions 

start-refs:  for  ref  in  REFLIST 

where  ( {ref- journal  =  journal) 
and  (ref .  paper  =  paper) )  do 
instantiate  REFEREE-NET (ref -referee? 
paper, editor) 

exc-handler  e hi  for  NO-REF-REPLY 
is  REF-DOESN'T-ANSWER; 
exc-handler  eh2  for  REPORT-LATE 
is  REPORT-NO T-RECEIVED ; 
end  have-referees; 


referee-refusal: 

from  f 1 :  waiting-ref-replies; 
to  tl:  waiting-new-ref-na me s; 
conditions 

one-or-more-ref s- refuse? : 

(begin 

locals 

refusal:  BOOLEAN; 
actions 

al:  for  ref  in  REFLIST 

where ( (ref . journal  =  journal) 
and  (ref- paper  =  paper))  do 
if  giving  (ref,  referee , paper, 

journal) . ref eree-net , reply : NO)  =  true 
then  refusal  < —  true ; 

returns 
rtn:  refusal; 
end)  =  true; 

actions 

delete-refusing-refs: 

for  ref  in  REFLIST 
where  { (ref . journal  =  journal) 
and  (ref .  pa  per  =  paper))  do 

if  giving  f (ref . referee , pa per, journal) -referee-net, 
reply:  NO)  =  true  then 
begin 
actions 

al:  take  ( (ref.  referee, paper, 

journal) -referee-net , reply : NO)  ; 
a2:  delete-obiect  ref  in  REFLIST; 
end ; 

ask-new-refs:  ask  (editor. code, not  nothing  = 

fget-ob iect  ref  in  REFLIST 
where (  (ref -journal  =  journal) 
and  (ref-  paper  =  paper) 
and (  (ref -referee , paper, 

journal) -referee-net  =  nothing) ) ) )  ; 
all-new-refs-in?:  s-reguest  (editor -code  ,new-refs-in)  ; 
set-wait- time :  new-ref-time  < —  current-time; 
end  referee-refusal; 
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new-ref-names-late: 

from  fls  waiting- new-ref-na me s; 
to  tl:  waiting-new-ref-names; 
conditions 

time-exceeded?:  (current- time  -  new-ref-time)  >  6  0480  0; 
n ew-refs- not-in?:  new-refs-in  =  unknown  or 

new-refs-in  =  false: 

actions 

ask-again:  ask (editor. code, not  nothing  = 
fqet-obiect  ref  in  REFLIST 
where  ( (ref .  journal  =  journal) 
and  (ref  .paper  =  paper) 
and  { (ref . referee, paper, 

j ournal)  .  referee-net  =  nothing) ) )  )  : 
new-refs-in?:  s-reguest (editor. code, new-refs-in) ; 
reset-time:  new-ref-time  < —  current-time; 
end  new-ref-names-late; 


have-new-refs: 

from  fl:  waiting-new-ref-names; 
to  tl:  waiting-ref-replies; 
conditions 

new-refs?:  new-refs-in  =  true 
actions 

start-new-refs:  for  ref  in  REFLIST 

where  ( (ref .  journal  =  journal) 
and  (ref .paper  =  paper) 
and  ( (ref.  referee,  pa  per, 

journal) . referee-net  =  nothing) ) do 
instantiate  REFEREE-NET  (ref-referee, 
paper, editor) 

exc- handler  ehl  for  NO-REF-REPLY 
is  REF-DOESN'T-ANSWER; 
exc-handler  eh2  for  REPORT-LATE 
is  REPORT-NOT-RECEIVED; 

end  have-new-refs; 


referees-all-agree: 

from  fl:  waiting-ref-replies; 
to  tl:  waiting-reports; 
conditions 

all-refs-agree? :  /*  This  condition  reguires  that  all 

proposed  referees  agree  to  review  the  paper  */ 
f begin 
locals 

agree:  BOOLEAN; 
actions 

al:  agree  <--  true : 
a2:  for  ref  in  REFLIST 

where  { (ref . journal  =  journal) 
and  (ref,  paper  =  paper)  )  do 
if  giving f fref. referee .paper , 

journal) . referee-net, reply : YES)  =  false 
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then  agree  < —  false ; 

returns 

rtn:  agree; 
end)  =  true ; 

actions 

take-replies:  for  ref  in  REFLIST 

where  f  (ref . journal  =  journal) 
and  (ref . paper  =  paper)) do 
take ( (ref .referee,paper, journal) .referee-net , 
reply:YES) ; 

end  referees-all-agree ; 


a 11- reports- in: 

from  fl:  waiting-reports; 
to  tl:  waiting-decision; 
conditions 

all-reports-in?:  /*  This  condition  requires  that  all 

reports  be  in  before  the  editor  considers  any  of  them  * 
(begin 
locals 

reports-in:  BOOLEAN; 
actions 

al:  reports-in  < —  true: 
a2:  for  ref  in  REFLIST 

where  (  (ref .  journal  =  journal) 
and  (ref .  paper  =  paper))  do 
if  giving  (  fref  .referee, paper, 

journal) . ref eree-net ,report-in: BOOLEAN)  = 
false  then  reports-in  < —  false : 

returns 

rtn:  reports-in; 
end)  =  true : 

actions 

complete-i/o:  for  ref  in  REFLIST 

where  ( (ref .  journal  =  journal) 
and  (ref . paper  =  paper)  )  do 
take  ( (ref.  ref eree ,paper ,  journal)  •  referee-net, 
report- in:  BOOLEAN); 
set-value:  reports-submit ted  < —  true: 
tell- editor:  s-inform  (editor. code  *  reports-submitted)  ; 
ask-decision:  s-reguest (editor. code, decision)  ; 
set-time:  decision- time  < —  current-time; 
end  all-reports-in; 


decision- late: 

from  fl:  waiting-decision; 
to  tl:  waiting-decision; 
conditions 

no-decision?:  decision  =  unknown: 

time-exceeded?:  current-time  -  decision-time  >  1209600; 
actions 

ask-decision-again:  s-reguest (editor. code, decision) ; 
reset-time:  decision-time  < —  current-time; 
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end  decision-late; 


decision- to- re vise : 

from  f 1 ;  waiting-decision; 
to  tl:  waiting-revision; 
conditions 

revising?:  decision  =  ’revise*; 
actions 

tell-author:  s-inf  orm  (author,  code,  decision)  ; 
ask- if- re  vision- in:  s-  re  g  ue  st  (author,  code  , 

revision-submitted) ; 

reset-value:  reports-submitted  < —  false: 
end  decision-to- re vise ; 


revision- in: 

from  fl:  waiting-revision; 
to  tl:  waiting-reports; 
conditions 

revision-in?:  revision-submitted  =  true; 
actions 

tell-refs:  for  ref  in  REFLIST 

where (  (ref . journal  =  journal) 
and  (ref,  paper  =  paper))  do 
£ive ( (ref . referee, paper, journal) .referee-net , 
revision-submitted) ; 
end  revision-in ; 


accept- or- re ject: 

from  fl:  waiting-decision; 
to  tl:  editor-finished; 
conditions 

accept-or-re ject ? :  decision  =  ’accept*  or 

decision  =  ’reject*; 

actions 

tell-author:  s^in form  (author. code , decision) ; 
stop-refs:  for  ref  in  REFLIST 

where  (  (ref .  journal  =  journal) 
and  (ref . paper  =  paper)) do 
terminate  REFEF.EE-NET  (ref .  referee, 
paper, journal) ; 

stop-editor:  terminate  EDITOR-NET (editor, paper, journa 1) ; 
end  accept-or-re ject; 


pa per- with drawn: 

from  fl:  waiting-paper-withdr awn; 
to  tl:  editor-finished; 
conditions 

paper-withdrawn?:  paper-withdrawn  =  true: 
actions 

stop-refs:  for  ref  in  REFLIST 

where [  (ref. journal  =  journal) 
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and  fref . paper  =  paper)) do 
begin 
actions 

al:  s- inform  f  fref. referee. code . 
paper- withdrawn)  ; 

a 2:  termin ate  REFEREE-NET  (ref . referee, 
paper ,  journal)  ; 

end: 

stop-editor:  terminate  EDITOR-NET  (editor , paper, journal) ; 
end  paper-withdrawn  ; 


end  EDITOR-NET; 


SCRIPT-CLASS  REFEREE-NET  with 


par ameter-list 

referee-net:  (ref eree  , paper , journal) ; 


locals 

referee:  REFEREE; 

paper:  PAPER; 

journal:  JOURNAL; 

editor:  EDITOR; 

ref-reply:  [J'yes',  ’no'll; 

postcard-time,  report-time,  no-reports, 

no-wait-reports  :  INTEGER; 

revised,  report-submitted:  BOOLEAN; 

starting-ref-net  default  'on*  ,  waiting-ref-reply, 

ref-refusal,  waiting-ref-report,  waiting-revision:  STATE; 


transit ion- list 


initial-request : 

from  fl:  starting-ref-net; 
to  tl:  waiting-ref-reply; 
actions 

ask-ref:  s^resuest (referee. code, ref-reply) ; 
set-editor:  editor  < —  journal. editor ; 
set-time:  postcard-time  < —  current-time; 
set-no-requests:  no-requests  < —  1; 
end  initial- reguest ; 


ref eree- ref uses: 

from  fl:  waiting-ref-reply; 
to  tl:  ref-refusal; 
conditions 

refuses?:  ref-reply  =  'no'; 
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tell-editor:  s-  in  form  (editor,  code  ,  referee,  name,  ref-re  ply)  ; 
tell-editor-net :  give  ( (editor , paper,  journal)  .  editor-net, 

ref-reply) ; 
end  ref eree- ref uses ; 


reply-late: 

from  f 1 :  waiting-ref-reply; 
to  tl:  waiting-ref-reply; 
conditions 

no-reply?:  ref-reply  =  unknown: 

two-weeks-passed? :  current- time  -  postcard-time  >  1209600; 
actions 

ask-ref-again:  s^re^uest  (referee,  code, ref -reply) ; 
reset-time:  postcard-time  < —  current-time; 
count-reguests:  no- reguests  < —  no-reguests  +  1; 
postregs 

two-or-less?:  no-reguests  <=  2 

exc  excl  NO-REF-REPLY (ref-net: self .ref eree-net) ; 
end  reply-late; 


r eferee- accepts: 

from  fl :  waiting-ref-reply ; 
to  tl:  waiting-ref-report; 
conditions 

ref-accepts?:  ref-reply  =  ’yes*; 
actions 

tell-editor:  s^inform  (editor,  code,  ref  eree  .name, ref- re  ply)  ; 
tell-editor-net:  (give  ( (editor , paper,  journal)  .editor-net, 

ref- reply)  ; 

set-time:  report-time  < —  current-time; 

ask- for-report:  s- re guest (referee. code. re port -submitted) ; 
set-no-wait- re ports:  no-wait- reports  < —  1; 
end  ref eree-accepts ; 


report-late: 

from  f 1 :  waiting-ref-report; 
to  tl:  waiting-ref-report; 
conditions 

report-not-in?:  report-submitted  =  false: 
report-late?:  (current-time  -  report- time)  >  1209600; 
actions 

ask-again:  s-re^uest  (referee,  code , report-submitted) ; 
reset-time:  report-time  < —  current-time; 
count-reguests:  no-wait-reports  < —  no-wait-reports  +  1; 
postregs 

two-or-less?:  no-wait-reports  <=  2 

e^c  exc2  REPORT- LATE (ref-net : self . refe ree- net)  ; 
end  report- late; 


report-made: 

from  fl:  waiting-ref-report; 
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to  tl :  waiting-revision; 
conditions 

report-in?:  report-submitted  =  true; 
actions 

tell-editor-net :  give  (  (editor, paper,  journal)  .editor-net, 

report-submitted)  ; 
end  report-made; 


paper-revised : 

from  f 1 :  waiting- re  vision; 
to  tl:  waiting-ref-report ; 
conditions 

paper- revised?:  giving ( [editor, paper. journal) .editor- net, 

revised:  BOOLEAN)  =  true : 

actions 

ready- to- revise:  take  ( (editor , paper , journal) . editor-net, 

revised:  BOOLEAN; 

tell-ref:  s-inf or m (referee. code. revised) ; 
reset- time:  report-time  < —  current-time; 
reset-value:  report-submitted  < —  unknown : 
ask-for-report :  s-reguest  (referee. code. re  port-sub  mitt ed)  ; 
reset-count:  no-wait- reports  < —  1; 
end  paper-revised; 


end  REFEREE-NET; 


Finally,  since  no  transactions  are  needed  in  the  script,  we 
specify  the  script  exceptions  and  exception  handlers. 


EXCEPTION-CLASS  NO-REF-REPLY  with 
attributes 

ref-net:  REFEREE-NET; 
end  NO-REF-REPLY; 


EXCEPTION-CLASS  REPORT-LATE  with 
attributes 

ref-net:  REFEREE-NET; 
end  REPORT-LATE; 


Notice  that  the  only  attributes  property  of  each  exception  class  is 
just  the  instance  of  the  script  that  caused  the  exception  to  be 


raised.  From  this  instance  we  can  gain  all  the  information  we  need 
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about  the  circumstances  causing  the  exception. 


SCRIPT-CLASS  REF- DOESN’T -ANSWER  with 
parameter- list 

ref-doesn * t-answer :  (exception- parm) ; 
locals 

exception-parm:  NO-REF-REPLY; 


act  ions 

/*  Transitions  that  outline  some  sequence  of  actions  to  be 
taken  by  the  editor  when  a  referee  doesn’t  reply  within 
4  weeks.  Possible  actions  might  be  to  phone  the  referee 
personally  or  get  another  referee  */ 

end  RFF-DOESN* T-ANSWER; 


SCRIPT-CLASS  RE PORT-NOT -RECEIVED  with 
parameter- list 

report-not-received:  (exception-parm) ; 
locals 

exception-parm:  REPORT-LATE; 


actions 

/*  Transitions  to  resolve  a  late  report  by  a  referee  who 
has  agreed  to  referee  a  paper  */ 

end  REPORT-NOT-RECEIVED; 


4^2  A  Sample  Dialogue  Using  Thg.  EDITOR-NET  apd  REFEREE-NET  Scripts 


As  an  example  of  a  dialogue  possible  using  the  EDITOR-NET  and 
REFEREE-NET  scripts,  consider  the  following  scenario  of  events.  An 
author,  named  ’joe-author’,  submits  a  paper  to  a  journal  for 
publication.  The  journal's  editor,  * joe-editor  * ,  asks  three 
potential  referees,  * joe-refe ree 1 ' ,  ' joe-referee2 ' ,  and 
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* joe-referee3 '  tc  review  the  paper.  The  first  referee, 

'  joe- ref eree 1  * ,  declines  while  the  second  referee,  1  joe-ref eree 2* , 
consents.  The  third  referee,  ' joe-ref eree3 ’ ,  does  not  reply  within 
the  two  week  time  limit.  When  reminded,  however,  he  replies  in  the 
negative.  The  editor  decides  to  replace  the  two  refusing  referees 
with  only  one  new  referee,  ' joe-ref eree4 ' .  When  asked,  this  referee 
agrees  to  review  the  paper.  The  new  referee  is  late  with  his  report 
but  when  reminded  he  immediately  submits  it.  When  both  reports  are 
in,  the  editor  decides  the  paper  needs  revising  and  informs  the 
author  of  this  fact.  Once  the  revised  paper  is  submitted,  the 
editor  waits  for  new  reports  from  the  two  referees.  This  time, 
*  joe- referee2 1  is  late  with  his  report  and  so  is  reminded.  Once 
both  reports  are  submitted,  the  editor  procrastinates  for  over  two 
weeks.  When  reminded,  he  decides  to  accept  the  paper  for 
publication. 

Note  that,  as  in  Chapter  2,  the  person’s  name  is  used  as  the 
person’s  code.  Thus,  for  example,  ' joe-referee  1 •  is  equal  to 
joe-referee  1 . code  and  Mjoe-editor’  is  equal  to  joe-editor . code.  To 
further  enhance  readability,  ’paper*  will  be  used  as  the  paper’s 
title  and  ’journal’  will  be  used  as  the  journal's  name.  Also  note 
that  the  order  in  which  much  of  the  dialogue  is  presented  in  is 
arbitrary.  That  is,  it  is  impossible  to  tell  which  script  instance 
will  execute  a  dialogue  act  at  any  given  moment  because  of  their 
concurrency.  The  above  scenario  of  events  could  result  in  the 
following  dialogue  being  created: 
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joe-editor:  instantiate  EDITOR-NET (joe-editor, paper, journal) 

( joe- editor, paper , journal) .editor-net: 

s- inform  f 1  ioe-author1  , paper-received  < —  true) 
s-reguest  (• joe-author* , paper-withdrawn)  ; 
ask  (' joe-editor *, not  nothing  = 
fqet-obiect  ref  in  REFLIST 
where  f  (ref. editor  =  editor) 
and  (ref, paper  =  paper)))  ) 
s-reguest ( *  joe-editor • ,all-ref-names-in) 

/*  Editor  inserts  proposed  referee  names  in  REFLIST  */ 

joe-editor:  u-inform {  (joe-editor, paper, journal) .editor-net, 

all-ref-names-in  <--  true) 

( joe- refereel , paper, journal) . referee- net: 

s-reguest  ( *  joe- refereel * , ref-reply) 

joe-referee  1 :  u-inform  ( joe-refereel , paper , 

journal) . referee-net, ref-reply  <--  *no*) 

( joe- ref e reel , paper, journal) . referee- net : 

s-inform  f 1  joe-editor* .referee. name  < — 

*  joe-ref ereel *, ref- reply  < —  *no* ) 

/*  At  this  point  this  particular  referee  script  instance 
terminates  */ 

(joe-referee2, paper,  journal)  .  referee-net: 

s-reguest  (*  joe- referee2* , ref-reply) 

joe-referee2:  u-inform  (joe-referee2 , paper , 

journal) . referee- net, ref- reply  <--  yes) 

( joe- refer ee 2 , paper, journal) . referee- net: 

s-inform  ( *  joe- edit  or  * , referee. name  < — 

*  joe- ref eree2* , ref-reply  < —  *yes*) 
s-reguest ( *  joe-ref eree2  * , report-submitted) 

(joe- referee 3, paper, journal) . referee- net: 

s-reguest ( *  joe-referee  3  * , ref-reply) 

/*  Over  2  weeks  later  */ 

s-reguest  ( • joe-ref eree3  * ,ref-reply) 

joe-r eferee3 :  u-inform  ( ( joe- referee 3, paper, 

journal) . referee-net, ref-reply  <--  *no*) 

(joe-referee3, paper, journal) . referee-net: 

s-inform  ( *  joe-editor  * , ref eree. name  < — 

' joe-referee3* , ref-reply  < —  *no*) 

/*  At  this  point  this  referee  script  instance  terminates  */ 
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{joe-editor, paper, journal) . editor-net: 

ask  (* joe-editor *, not  nothing  = 
fget-ob iect  ref  in  REFLIST 
where  ( {ref . editor  =  editor) 
and  {ref  -  paper  =  paper) 

and  ( {ref.  referee, author, editor)  .ref  eree-net 
=  nothing) ) ) ) 

s- request ( *  joe-editor' ,new-ref s-in) 

joe-editor:  u-inform { (joe-editor, paper, journal)  .editor-net, 

new- ref s-in  < —  true) 

/*  Referees,  joe-refereel  and  joe-referee3,  have  been 
deleted  from  REFLIST  and  the  editor  has  added 
' joe-referee4 *  to  REFLIST  */ 

(joe-referee4, paper,  journal)  .  referee- net: 

s-reauest  ( ' joe-referee4  ' , ref-reply) 

joe-referee4 :  u-inform ( (joe-referee4, paper, 

journal)  . referee-net, ref-reply  < —  'yes') 

(joe-referee4, paper, journal) . referee-net: 

s- inform [ ' ioe-editor ' , referee. name  < — 

' joe-ref eree4' , ref-reply  < — '  'yes') 
s-reguest ( ' joe-ref eree4 ' , report-submitted) 

joe-r eferee2:  u-inform  ( (joe-referee 2, paper, 

journal)  . referee- net, report-submitted  < —  true) 

/*  Over  2  weeks  after  the  initial  reguest  joe-referee4 
is  reminded  to  submit  his  report  */ 

(joe-referee4, paper,  journal)  .  referee- net: 

s- request  ('  joe-referee4  ' ,  report-submitted) 

joe-referee4:  u-inform ( ( joe-refer ee4,paper, 

journal) . referee-net, report-submitted  < —  true) 

( joe-editor, paper , journal) . editor-net : 

s-inform (' joe- edit or ', reports- submit ted  <--  true) 
s- request ( ' joe-editor' , decision) 

joe-editor:  u^inform ( (joe-editor, paper, journal) .editor-net, 

decision  <--  'revise') 

(joe-editor, paper, journal) . editor-net: 

s-inform  f ' joe-author*  ^decision  <--  'revise') 
s- request  ( '  joe-author ' ,  revision-submitted) 

joe-author:  u-inform  f (ioe-editor , paper, journal) .editor-net, 

revision-submitted  < —  true) 

( joe- refer ee2 , paper, j  curnal) . referee- net: 

s- inform  (' joe-ref eree 2* ,re vised  < —  true) 
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s- request  ( *  joe-referee2  1 ,  report-submitted) 

(joe-referee4, paper,  journal)  .  referee-net: 

s-inf orm  f 1  joe-ref eree4'  ,revised  < —  true) 
s- request { *  joe-referee4 ' , report-submitted) 

joe-referee4:  u-inf orm  (  (joe-referee 4, paper, 

journal)  -  referee-net, report-submitted 
< —  true) 

/*  Over  2  weeks  after  initial  reguest  */ 

(joe- referee 2,  paper,  journal)  .  referee- net: 

s-  request  ( *  joe-ref  eree2 1  , re  port-submitted) 

joe- referee 2:  u-inform  (  ( joe-ref eree 2, paper , 

journal) . referee- net, report-submitted 
< —  true) 

(joe-editor, pa per, journal) .editor-net: 

s-  in  form  ('  joe-editor*  ,reports-submi  tted  < —  true) 
s-reauest  ( '  joe- editor ' , decision) 

/*  Over  2  weeks  later  */ 

s-reguest ( *  joe- edit or' , decision) 

joe-editor:  u-inf orm f 1  joe-editor* , decision  < —  ’accept*) 

(joe- edit or, pa per, journal) . editor-net: 

s-inf orm (* joe-author* , decision  < —  'accept*) 

/*  All  instances  of  REFEREE-NET  are  terminated  by  the  editor 
script  at  this  point,  after  which  the  editor  script  itself 
terminates.  */ 


4. 3  A  Specialization  of  the  EDITOR-NET  and,  REFEREE-NET  Script  s 

As  an  example  of  specialization  let  us  suppose  that  potentially 
important  papers  submitted  for  publication  by  distinguished  authors 
require  the  editor  to  designate  especially  well  qualified  referees. 
To  keep  the  specialization  simple  we  demonstrate  only  how  exception 
and  exception  handlers  are  specialized.  In  particular,  we 
specialize  REFEREE-NET  by  specializing  the  NO-REF-REPLY  and 
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REPORT-LATE  exceptions  to  include  information  about  the  special 
referee  and  special  author.  As  a  result  the  EDITOR-NET  script  must 
be  specialized  by  having  the  exception  handler  clauses  in  its  two 
instantiate  statements  specialized.  Following  the  program  design 
methodology  outlined  in  Chapter  3  the  specialized  data  classes  are 
presented  first. 


VARIA ELE-CIASS  SPECIAL-REFEREE  isa  REFEREE  with 
keys 

special-referee:  (name, address) ; 
attributes 

status:  STATUS; 
end  SPECIAL-REFEREE; 


VARIABLE-CLASS  SPECIAL-AUTHOR  isa  AUTHOR  with 
keys 

special-author:  (name , address) ; 
attributes 

awards:  AWARDS; 
publications:  PUBLICATIONS; 
end  SPECIAL-AUTHOR; 


VARIABLE-CLASS  SPECIAL-PAPER  isa  PAPER  with 
keys 

special-paper:  (author,  title)  ; 
characteristics 

author:  SPECIAL-AUTHOR; 
end  SPECIAL-PAPER; 


VARIABLE-CLASS  S PECI AL-REFLIST  isa  REFLIST  vith 
keys 

special-reflist:  (journal , special-paper , special-referee)  ; 
characteristics 

special-paper:  SPECIAL-PAPER; 
special- referee:  SPECIAL- REFEREE; 
end  SPECIAL-PAPER; 


Again  no  transactions  are  needed.  To  specialize  the  scripts  we  use 
implicit  (versus  explicit)  specialization.  We  now  present  the 
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specialized  transitions  necessary  for  both  the  referee  and  editor 
scripts  and  then  the  specialized  exceptions. 


transition  reply- late  on 

(SPECIAL-REFEREE, SPECIAL-PAPER, JOURNAL)  . .referee-net  is 
postregs 

more- 2-reguests:  no-reguests  <=  2  exc  excl 

NO-SPECIAL-REF-REPLY (ref-net : sel f . re  fere  e-net) ; 


transition  re port- late  on 

”  (SPECIAL-REFEREE, SPECIAL-PAPER, JOURNAL) . . referee-net  is 
postregs 

two-or-raore? :  no-wait-reports  <=  2  exc  exc2 

SPECIAL-REPORT- LATE (ref-net : sel f. ref eree-net) ; 


transition  have-referees  on 

(EDITOR, SPECIAL-PAPER, JOURNAL) . .editor-net  is 
action 

start-refs:  for  ref  in  SPECIAL- REFLIST 

where  f  (ref,  journal  =  journal) 
and  (ref .  paper  =  paper) )  do 
instantiate  REFEPEE-NET (ref , paper , JOURNAL) 
exc-handler  ehl  for  NO-SPECIAL-REF-REPLY 
is  REF-DOESN'T-ANSWER 
exc-handler  eh2  for  SPECIAL-REPOPT-LATE 
is  REPORT-NOT-RECEIVED; 


transition  ha ve-new-ref erees  on 
’  (JOURNAL, SPECIAL-PAPER)  . . JOURNAL-net  is 
actions 

start-new-ref s:  for  ref  in  SPECIAL-REFLIST 

where  (  (ref.  JOURNAL  =  JOURNAL) 
and  (ref  .paper  =  paper) 

and  ( (ref . referee , paper, journal) . ref eree-net 
=  nothing) ) do 

instantiate  REFEREE-NET  (ref , paper , journal) 
exc-handler  ehl  for  NO-SPECIAL-REF-REPLY 
is  REF-DOESN  *T- ANSWER 
exc-handler  eh2  for  SPECIAL-REPORT-LATE 
is  REPORT-NOT-RECEIVED; 


Next  we  give  the  specialized  exception  classes  needed. 

EXCEPTION-CLASS  NO-SPECIAL-REF-REPLY  isa  NO-REF-REPLY  with 
attributes 

ref-net?  (SPECIAL-REFEREE, SPECIAL-AUTHOR, JOURNAL)  . .referee-net; 
end  NO-SPECIAL-REF-REPLY; 
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EXCEPTION-CLASS  S PEC I A L- REPORT- LATE  isa  REPORT-LATE  with 
attributes 

ref-net:  (SPECIAL-REFEREE , SPECIAL- AUTHOR, JOURNAL) . . referee-net ; 
end  SPECIAL-REPOST-LATE; 

Finally  we  must  specialize  the  script  exception  handlers  for  the  two 
specialized  exceptions.  This  would  involve  adding  or  specializing 
transitions  of  the  REF-DOESN ' T-ANS  WER  and  F.EPORT-NOT-R  ECEI VED 
scripts.  These  transitions  could  add  new  or  specialized  conditions, 
actions,  or  postrequisites  to  the  scripts.  To  keep  things  simple  we 
just  show  how  a  transition  would  be  added  or  specialized  for  each  of 
the  exception  handler  scripts. 


trans ition  /*  An  old  or  new  transition  name  */  on 
(NO-SPECIAL-REF-REPLY) . . ref-doesn ' t-answer  is 
/*  new  or  specialized  property  definitions  */ 


transition  /*  An  old  or  new  transition  name  */  on 
(SPFCIA L-REPOPT-LAT E) . . report-n ot-recei ved  is 
/*  new  or  specialized  property  definitions  */ 
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Related  Research 


5il  Introduction 

In  this  chapter  we  discuss  some  of  the  current  research  with 
goals  similar  to  those  of  this  thesis.  The  discussion  is  by  no 
means  a  complete  survey  of  such  work,  as  it  only  concentrates  on 
work  that  has  influenced  the  design  of  script  and  transition 
metaclasses. 

The  discussion  is  divided  into  four  parts.  First  we  discuss 
two  office  automation  systems  (namely  SCOOP  [Zisman  77  and  78]  and 
OFS  ([Gibbs  79]  and  [Cheung  79])  and  their  relevance  to  TAXIS.  Next 
we  compare  and  contrast  two  office  automation  languages  (namely  OFSL 
[Zisman  77  and  78]  and  BDL  [Hammer  et  al  77])  with  TAXIS.  Thirdly, 
we  survey  three  natural  language  front  end  systems,  RENDEZVOUS  [Codd 
et  al  78],  PLANES  [Waltz  78],  and  LIFER  [Hendrix  77  and  78],  placing 
particular  emphasize  on  the  dialogue  facilities  each  system 
supports.  Finally  we  discuss  the  types  of  dialogue  that  TAXIS 
scripts  (and  TAXIS  in  general)  can  model. 

5. 2  Office  Automation  Systems 

In  this  section  we  present  a  discussion  of  two  office 

automation  systems,  SCOOP  and  OFS.  We  compare  and  contrast  the 
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capabilities  of  these  systems  with  TAXIS. 

5.  2.  1  SCOOP 

In  the  previous  chapter  we  discussed  a  modified  version  of 
Zisman* s  editor  and  referee  office  procedures  [Zisman  77  and  78]  and 
showed  how  they  could  be  represented  in  TAXIS.  In  this  section  we 
describe  SCOOP  (which  stands  for  System  for  Computerization  Of 
Office  Processes),  which  is  currently  being  used  to  run  Zisman's 
version  of  these  two  procedures  for  papers  submitted  to  the 
Management  Application  Section  of  CACM  and  for  some  of  the  papers 
submitted  to  TODS. 

Zisman* s  editor  and  referee  procedures  are  implemented  in  SCOOP 
using  his  APN  representation.  Instances  of  these  procedures  can  be 
running  concurrently.  For  example,  the  editor  procedure  can  have 
several  instances  of  itself  running,  an  instance  for  each  paper 
being  processed  by  SCOOP. 

SCOOP  conducts  dialogue  with  users  by  employing  a  system  called 
reponse  mail.  This  system  uses  documents  which  are  like  interactive 
letters  [Zisman  77],  in  that  a  document  sent  to  a  user  can  have  a 
question/answer  dialogue  associated  with  it.  By  answering  these 
questions,  the  user  can  respond  to  the  documents  message.  The  user 
does  not  have  to  respond  immediately  to  a  document;  instead  he  can 
file  the  document  away  in  one  of  his  electronic  folders.  When  he 
wishes  to  respond,  he  retrieves  the  document  and  replies  to  each  of 
the  questions  as  they  are  posed  to  him.  Each  reply  is  validated 
according  to  some  editing  instructions  that  are  part  of  the 
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question/answer  dialogue.  When  the  dialogue  has  been  completed,  the 
user's  response  is  formatted  and  mailed  back  to  the  system. 

SCOOP  procedures  are  event  driven  in  that  SCOOP  reacts  to  user 
input  {or  lack  of  it)  by  performing  prespecified  actions  such  as 
generating  documents  or  using  the  electronic  mail  system.  When 
SCOOP  is  executed  it  reads  all  its  incoming  mail.  SCOOP  accepts  all 
new  user  inputs  {which  can  only  be  created  using  the  response  mail 
system)  and  updates  the  appropriate  procedure  instances.  This  can, 
in  turn,  cause  SCOOP  to  mail  newly  generated  documents  to  the 
appropriate  users  and  wait  for  their  response.  This  execution  cycle 
continues  while  any  procedure  instances  still  exist. 

SCOOP  has  two  major  data  structures;  a  procedure  structure 
where  the  actual  office  procedure  specification  is  outlined  and  an 
instance  structure  which  contains  all  the  data  about  a  particular 
procedure  instance.  These  two  data  structures  are  comparable  to 
TAXIS  script  definitions  and  their  instances. 

All  procedure  instances  are  organized  into  instance  trees  with 
each  procedure  instance  called  by  a  particular  procedure  instance 
being  the  child  node  of  that  instance.  Eor  example,  each  editor 
instance  can  call  (i.e.  create)  several  referee  instances  {i.e. 
one  instance  for  each  referee  reguired) .  This  would  create  an 
instance  tree  with  the  editor  instance  as  the  parent  node  and  each 
referee  instance  as  a  child  node.  Global  variables  are  used  to 
carry  out  communication  between  child  nodes  and  their  parent  nodes 
or  between  child  nodes  with  a  common  parent  node. 
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Zisman  describes  several  limitations  associated  with  this 
design  [Zisman  77].  First,  data  is  global  only  to  particular 
instance  trees  and  is  not  global  to  several  instance  trees.  Thus 
for  procedure  instances  in  different  instances  trees  to  interact  or 
share  data  they  must  access  data  in  a  common  file.  Zisman  indicates 
that  this  is  an  unsatisfactory  solution  and  that  a  database 
interface  would  be  more  desirable.  A  second  limitation,  closely 
related  to  the  first,  is  that  data  declared  locally  in  a  procedure 
instance  cannot  be  accessed  by  its  parent  node.  This  problem  can  be 
avoided  by  declaring  all  such  data  in  the  parent  node  and  letting 
its  children  nodes  update  it.  However,  having  to  do  this  is  a 
design  weakness  of  SCOOP.  These  two  problems  do  not  arise  in  TAXIS 
scripts  (which  do  not  have  global  variables)  .  Script  instances  can 
communicate  and  interact  with  each  other  by  either  accessing  TAXIS 
data  classes  (which  are  global  to  all  script  instances),  as 
suggested  by  Zisman  above,  or  b y  using  I/O  commands  and  predicates 
(as  demonstrated  in  the  last  chapter)  • 

A  third  limitation  of  SCOOP,  mentioned  by  Zisman,  is  that  only 
data  asked  for  by  the  system  can  be  input.  That  is,  the  only  way  to 
perform  dialogue  with  SCOOP  is  through  the  reponse  mail  facility. 
This  limitation  also  applies  to  TAXIS  scripts.  Zisman  argues  that 
all  procedure  instances  will  not  exactly  follow  the  algorithm 
encoded  in  the  procedure  definition  and  that,  as  a  result,  a 
facility  should  exist  so  that  SCOOP  can  be  instructed  to  take 
actions  other  than  those  specified  in  the  procedure  definition. 
Thus,  a  user  would  be  able  to  change  the  current  marking  and 
variable  values  of  a  procedure  instance.  We  argue  that  this  is 
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undesirable  because  allowing  a  user  to  arbitrarily  change  the 
current  marking  and/or  variable  values  of  a  procedure  instance  can 
lead  to  disasterous  errors.  Instead  the  procedure  definition  should 
be  designed  to  allow  the  user  to  change  the  current  marking  (by 
firing  the  appropriate  transitions)  and/or  variable  values  in  a 
structured  manner.  TAXIS  scripts  also  have  an  exception  handling 
mechanism  that  can  be  activated  when  unexpected  events  occur. 

A  final  limitation  of  SCOOP,  which  Zisman  considers  an 
implementation  rather  than  a  design  limitation,  is  that  SCOOP  has  no 
guery  capability.  That  is,  if  a  user  wishes  to  check  the  status  of 
some  procedure  instance,  he  must  review  a  report  of  all  instances. 
This  problem  does  not  exist  in  TAXIS  as  a  user  can  access  local 
variables  of  any  script  instance  (or,  for  that  matter,  the  script 
instance  itself)  by  using  u- re  guest  commands. 

Zisman  mentions  in  his  thesis  that  additional  detail  can  easily 
b€  added  to  existing  APNs  in  SCOOP.  That  is,  it  is  easy  to  add 
production  rules,  transitions,  and  places  to  existing  APN  networks 
without  having  to  modify  existing  instances  of  these  nets.  TAXIS 
enhances  this  ability  in  terms  of  stepwise  refinement  through 
specialization . 

As  can  be  seen  from  the  above  description,  SCOOP  is  more  than 
just  a  computer  information  storage  and  retrieval  system  [Zisman 
77],  SCOOP  actually  attempts  to  automate  both  the  role  and  tools  of 
its  users  while  existing  office  systems  usually  just  automate  the 
user’s  tools.  TAXIS  has  the  ability  to  do  this  also.  This  type  of 
system  represents  a  significant  advance  over  previously  existing 
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office  automation  software. 

5.2.2  QFS 

[Gibbs  79]  and  [Cheung  79]  has  designed  and  implemented  OFS 
(for  Office  Form  System)  at  the  University  of  Toronto.  Form  filling 
is  used  to  conduct  dialogue.  This  form  system  has  commands  that  can 

1)  fill  out  a  form 

2)  modify  a  form 

3)  copy  a  form 

4)  mail  a  form 

5)  locate  a  form 

6)  trace  a  form 

7)  print  a  form 

8)  attach  a  form  to  a  dossier 

9)  retrieve  a  form 

10)  retrieve  a  dossier 

11)  retrieve  mail 

12)  dispose  of  a  form 

"Stations"  are  the  places  where  OFS  form  commands  are  issued.  The 
capabilities  of  different  stations  vary  according  to  the  task  being 
carried  out  at  the  station.  Each  station  has  its  own  partition  of 
the  forms  database,  thus  enabling  stations  to  have  private  files. 
Forms  are  filled  out  at  stations  and  mailed  from  station  to  station. 

Each  form  can  have  six  types  of  fields.  TYPEK  fields  are  keys 
that  identify  form  instances  uniquely.  As  such  they  are 
automatically  created  by  the  system  and  cannot  be  modified  by  a 
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user.  TYPE  1  fields  must  be  filled  out  as  soon  as  a  form  instance  is 
created  and  cannot  be  modified  by  a  user.  TYPE2  fields  can  be 
entered  at  any  time  after  a  form  instance  has  been  created,  but  once 
they  have  been  entered  they  cannot  be  modified.  TYPE 3  fields  can  be 
filled  out  and  modified  at  any  time.  TYPED  fields  are  date  fields 
that  are  automatically  filled  for  each  form  instance  and  cannot  be 
modified.  Finally  TYPES  fields  are  signature  fields.  Each  time  a 
form  field  is  created  or  modified  in  any  way  at  a  station,  the 
signature  of  that  station  is  automatically  attached  to  that  field. 

Three  types  of  stations  exist  in  OFS.  Host  stations  are 
concerned  primarily  with  mail  transfers.  User  stations  provide  an 
interactive  facility  for  entering  or  retrieving  forms  from  the 
system.  Automated  stations  manipulate  the  forms  database  using  a 
predetermined  set  of  operations.  Automated  stations  perform  such 
tasks  as  form  disposal  and  providing  hardcopy  of  forms.  Since  each 
station  represents  a  separate  process,  a  high  degree  of  concurrency 
is  possible. 

As  an  illustration  of  OFS’s  operations,  Gibbs  [Gibbs  79]  has 
implemented  a  simple  inventory  system.  Whenever  an  office  worker 
(i.e.  a  user)  needs  an  item  from  the  company’s  inventory  he  must 
contact  the  person  in  charge  of  entering  orders  for  office  supplies 
(i.e.  the  orderer) .  The  resulting  order  reguest  (represented  as  a 
form)  is  sent  to  a  third  person  (i.e.  the  updater)  who  distributes 
items  from  the  company’s  inventory  and  ensures  the  inventory  records 
are  updated.  The  updater  also  produces  an  invoice  form  and  send 
copies  of  it  to  the  user  and  the  accounting  department.  The 
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original  invoice  is  kept  by  the  updater,  while  the  original  order 
form  is  returned  to  the  orderer  along  with  an  indication  of  whether 
the  order  has  been  filled  or  not.  This  system  is  represented  in  OFS 
using  five  stations  (*) .  The  'ord'  station  is  used  by  the  orderer 
to  enter  the  order  form  and  receive  a  copy  of  the  invoice  and  the 
returned  order  form.  The  'upd*  station  is  a  fully  automated  station 
that  accepts  order  forms,  processes  them  by  updating  the  inventory 
database  if  the  reguired  number  of  items  are  available,  and  mails 
copies  of  the  invoice  to  the  'user'  station  and  the  'prt'  station. 
It  also  returns  the  order  form  to  the  'ord'  station.  The  'prt* 
station  merely  prints  all  forms  mailed  to  it.  The  'user*  station 
accepts  invoices  from  the  'upd*  station  as  they  are  sent.  If  more 
than  one  officer  worker  needs  supplies  from  the  company's  inventory 
at  the  same  time,  then  the  order  forms  (which  represent  transactions 
on  the  inventory  database)  are  batched  in  the  order  received.  All 
mail  transfers  are,  of  course,  handled  by  a  host  station. 

It  should  be  obvious  to  the  reader  that  the  above  inventory 
system  can  be  modelled  using  TAXIS  scripts.  Forms  would  be 
represented  using  TAXIS  variable  classes.  Five  scripts,  one 
corresponding  for  each  of  the  five  stations  mentioned  above,  would 
be  necessary:  an  orderer  script,  an  updater  script,  a  user  script, 
a  print  script,  and  a  host  script.  The  host  script  would  monitor 
the  other  four  scripts  and  perform  input  or  output  of  forms 


(*)  Gibbs  actually  specifies  only  four  stations  in  his 
inventory  system  with  the  fifth  station  (i.e.  the  host  station) 
being  an  "invisible"  station. 
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depending  on  whether  these  scripts  are  receiving  or  sending  mail. 
The  monitoring  of  these  scripts  would  be  accomplished  using  I/O 
predicates  while  the  actual  transfer  of  mail  would  be  accomplished 
using  I/O  commands.  If  the  host  script  has  no  mail  available  for  a 
script  requesting  its  mail,  it  sends  it  a  message  (i.  e.  a  form) 
indicating  this.  Thus,  as  in  a  real  office  situation,  a  script  user 
can  send  mail  to  another  script  user  but  has  no  guarantee  that  the 
intended  recipient  will  receive  it  (i.e.  the  recipient  must  pick  up 
his  mail) .  A  host  script  can  also  keep  a  log  of  each  form's 
movements  (as  can  OFS) .  The  orderer  script  would  conduct  dialogue 
with  the  orderer  to  fill  out  an  order  form.  As  such  it  would 
automatically  fill  out  all  TYPEK,  TYPED,  and  TYPES  fields  in  the 
form  and  would  not  allow  transfer  or  storage  of  that  form  until  at 
least  all  its  TYPE1  fields  have  been  filled.  The  orderer  script 
would  also  have  a  mail  facility  for  sending  new  forms  or  recieving 
invoice  forms  and  processed  order  forms.  This  communication  with 
the  host  script  would  be  handled  using  give  and  take  commands.  The 
updater  script  would  read  all  its  mail  (if  any)  at  periodic 
intervals  of  time  and,  for  each  order  form,  update  the  inventory 
database  (if  possible).  It  would  then  mail  the  processed  order  form 
back  to  the  orderer  script  and  send  a  copy  of  the  invoice  form 
created  as  a  result  of  the  transaction  to  each  of  the  user  and  print 
scripts.  The  user  script,  besides  processing  any  other  tasks 
assigned  to  it,  would  periodically  check  for  incomming  mail  and 
accept  any  invoice  forms  as  they  become  available.  The  print  script 
would,  of  course,  output  hardcopy  versions  of  all  forms  mailed  to 
it.  These  scripts  can  all  be  running  concurrently.  As  a  result,  it 
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is  possible  for  the  orderer  to  be  entering  a  new  order  form  while 
the  updater,  user,  and  print  scripts  are  processing  previously 
entered  order  forms. 

Gibbs  states  that  the  addition  or  deletion  of  stations  in  OFS 
is  a  straightforward  matter  (because  of  the  independent  nature  of 
each  station) .  The  same  holds  true  for  the  addition  or  deletion  of 
TAXIS  scripts.  In  both  cases  only  the  communication  facilities  of 
existing  stations  or  scripts  would  have  to  be  modified. 

OFS  appears  to  be  a  specialized  implementation  tool  that  deals 
specifically  with  office  automation  systems.  TAXIS,  on  the  other 
hand,  deals  with  the  design  of  IISs  in  general,  with  office 
automation  systems  being  just  one  type  of  IISs.  Since  office 
automation  will  reguire  a  lot  of  office  procedures  [Tsichritzis  79], 
stepwise  refinement  through  specialization  can  be  very  useful  for 
organizing  the  details  of  these  procedures. 

5.3  Office  Automation  Languages 

In  this  section  we  present  two  office  automation  languages, 
OPSL  and  BDL .  We  compare  and  contrast  the  facilities  offered  by 
these  languages  with  TAXIS  and  discuss  the  different  design 
philosophies  and  programming  methodologies  proposed  by  their 


authors. 
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5_._3._1  OPS  I 

Zisman  [Zisman  77]  has  proposed  a  prototype  language,  OPSL  (for 
Office  Procedure  Specification  Language) ,  which  is  to  be  used  to 
describe  office  procedures  to  the  SCOOP  system.  OPSL  is  a 
non-procedural  language  in  that  a  programmer  specifies  what  is  to  be 
done  and  not  how.  OPSL's  goal  is  to  provide  an  office  analyst  with 
a  small  number  of  operations  that  are  powerful  enough  to  describe  a 
wide  range  of  office  procedures.  Thus  an  office  analyst  would  use 
OPSL  to  describe  the  ways  in  which  SCOOP  should  process  input 
messages,  what  documents  should  be  generated  and  when  they  should  be 
mailed,  what  to  do  when  an  expected  response  to  an  interactive 
letter  is  not  forthcoming,  and  how  the  user's  file  space  should  be 
organized  and  maintained.  As  such  an  office  analyst's  duties  would 
be  comparable  to  those  of  a  database  adminstrator . 

An  OPSL  compilation  would  convert  an  analyst's  program  of  an 
office  procedure  into  an  APN  data  structure  ready  for  execution  by 
SCOOP.  An  OPSL  program  is  divided  into  three  sections,  each 
specified  in  the  following  order: 

1)  The  document  definition  section  is  used  to  specify  the 
definition  (i.e.  templates)  of  documents  to  be  used  within  the 
program. 

2)  The  activity  initiation  section  is  used  to  specify  when 
activities  are  to  be  performed.  This  section  can  be  thought  of  as 
specifying  the  conditions  necessary  for  the  occurrence  of  events  in 


SCOOP. 
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3)  The  activity  detail  section  is  used  to  specify  exactly  what 
actions  are  to  be  taken  when  an  activity  is  invoked. 

The  organization  of  OPSL  programs  is  similar  to  TAXIS  programs  in 
many  ways.  The  document  definition  section  of  an  OPSL  program 
corresponds  to  TAXIS  data  classes.  The  activity  initiation  and 
activity  detail  sections  together  correspond  to  scripts  with  the 
conditions  and  details  (i.e.  actions)  associated  with  each  activity 
corresponding  to  a  transition. 

One  important  difference  exists  between  OPSL  and  TAXIS;  OPSL 
is  relatively  non-procedural  while  TAXIS  is  procedural  in  the  sense 
that  how  everything  is  done  must  be  specified  in  all  its  detail. 
Since  the  users  of  both  languages  are  to  be  well  trained 
individuals,  the  procedurality  of  TAXIS  should  pose  no  problems. 

5.  3.  2  BDL 


Hammer  and  others  [Hammer  et  al  77]  have  designed  a  language, 
called  BDL  (for  Business  Definition  Language),  for  programming 
business  data  processing  problems  in  a  modular  and  structured 
manner.  The  manual  methods  used  by  people  in  the  business  world 
have  heavily  influenced  the  design  of  BDL.  As  a  result,  BDL  imposes 
a  specific  programming  methodology  on  the  programmer. 

BDL  has  the  following  four  types  of  objects: 

1)  Documents  (i.e.  forms)  are  the  basic  data  structure  used,  not 
only  for  the  input/output  of  data  in  a  program,  but  also  as  an 
internal  representation  of  data  within  a  program. 
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2)  Steps  are  used  to  perform  calculations  within  BDL  programs.. 
Irreducible  steps  are  primitive  steps  that  describe  how  input 
documents  are  transformed  into  output  documents.  Composite  steps 
are  formed  from  two  or  more  primitive  steps  (and/or  composite 
steps)  . 

3)  Paths  are  used  to  connect  steps.  Documents  move  between  steps 
over  connecting  paths. 

4)  Files  are  permanent  collections  of  documents. 

These  objects  are  related  to  each  other  in  a  BDL  program  by  the 
following  three  components: 

1)  FDC  (Form  Definition  Component)  defines  the  form  (i.e. 
template)  of  documents  to  be  used  in  a  program. 

2)  DFC  (Document  Flow  Component)  defines  the  relationships  and 
overall  organization  of  steps. 

3)  DTC  (Document  Transformation  Component)  specifies  how 
primitive  steps  produce  output  documents  from  their  input  documents. 

The  Form  Definition  Component  (FDC)  of  a  BDL  program  is  similar 
to  both  the  document  definition  section  of  an  OPSL  program  (see  last 
section)  and  the  data  classes  of  a  TAXIS  program.  Forms  specified 
in  FDC  are  the  templates  that  documents  can  exist  in.  They  can 
contain  prespecified  information  plus  specifications  about  what  kind 
cf  data  can  be  used  to  fill  them  out.  Special  data  types,  such  as 
ADDRESS,  DATE,  and  DOLLARS,  are  built  directly  into  the  language. 
(This  can  also  be  accomplished  in  TAXIS  using  form- defined  and 
test-defined  class  definitions).  Also  both  BDL  forms  and  TAXIS 
variable  classes  support  aggregation. 
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The  Document  Flow  Component  (DFC)  of  a  BDL  program  is  expressed 
in  a  2-D  graphical  language  corresponding  to  a  graphical 
representation  of  the  hierarchical  structure  and  relationships  of 
the  functions  of  a  program.  This  graphical  representation  (which 
consists  of  rectangulars  for  steps,  circles  for  files,  and  arrows 
for  paths)  is  similar  to  the  APN  representation  of  a  TAXIS  program. 
A  BDL  programmer  first  describes  his  application  in  a  very  general 
level  in  terms  of  composite  (and  primitive)  steps  and  their 
relationships.  Then  he  repeatedly  refines  the  composite  steps  in 
terms  of  more  specialized  composite  (and  primitive)  steps  and  their 
relationships  until  the  application  has  been  fully  described  in 
terms  of  primitive  steps  and  their  relationships. 

A  primitive  step  is  executed  when  all  its  input  paths  have 
groups  of  documents  (with  each  group  having  at  least  one  document  in 
it)  available  on  them.  When  a  primitive  step  executes,  it  takes  a 
document  group  at  each  of  its  input  paths,  processes  them  as 
specified  in  DTC,  and  creates  an  output  document  group  at  each  of 
its  output  paths.  These  output  document  groups  flow  along  their 
paths  to  other  primitive  steps  where  the  above  process  continues. 
Composite  steps  are  executed  by  executing  the  primitive  steps  that 
constitute  them.  If  a  path  should  have  more  than  one  document  group 
available  on  it,  then  the  first  available  group  is  used.  (Note  that 
two  or  more  document  groups  of  the  same  type  available  on  a  path  do 
not  merge  to  form  one  larger  document  group  but  rather  remain 
separate) .  Once  document  groups  are  used  by  a  step  they  are 
destroyed;  output  from  that  step  is  one  or  more  new  document 
groups.  Files,  on  the  other  hand,  can  keep  one  type  of  document  for 
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a  longer  period  of  time.  A  file  can  be  accessed  by  only  one  step  at 
a  time;  any  other  step  wishing  to  access  it  must  wait.  Hammer 
[Hammer  et  al  77]  does  not  specify  if  concurrent  execution  of  two  or 
more  steps  can  occur. 

As  can  be  seen  from  the  above  description,  DFC  corresponds  to 
the  activity  initiation  section  of  an  OFSL  program.  The  graphical 
representation  of  a  BDL  program  is  almost  equivalent  to  the  APN 
representation  of  a  TAXIS  program.  BDL  steps  are  comparable  to 
TAXIS  transitions  while  documents  are  comparable  to  APN  tokens. 

The  Document  Transformation  Component  (DTC)  of  a  BDL  program 
specifies  the  actual  computation  that  takes  places  in  each  primitive 
step.  The  general  structure  of  a  DTC  step  (which  has  a  tabular 
syntax  form)  is  predetermined  and  is  the  same  for  all  steps.  DTC 
has  a  small,  rather  restricted  set  of  operations  for  acting  on  input 
document  groups  to  create  output  document  groups.  As  can  be  seen 
from  above,  DTC  is  similar  to  the  activity  detail  section  of  OPSL. 
DFC  and  DTC  together  correspond  to  TAXIS  scripts. 

As  a  result  of  the  restricted  set  of  operations  available  in 
BDL  there  is  usually  only  one  way  to  do  a  particular  task.  That  is, 
BDL  is  different  from  most  other  programming  languages  in  that  it 
has  built  in  style  and  structure.  BDL's  design  philosophy  is  to 
remove  the  responsibility  from  the  programmer  about  which  of  several 
methods  to  use  to  accomplish  a  specific  task  by  forcing  him  to  use  a 
predetermined  method.  Hammer  argues  that  general  purpose  languages 
usually  are  very  complex  or  are  only  moderately  suitable  to  any  one 
application  area.  TAXIS,  while  being  more  general  purpose  than  BDL, 
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has  been  specifically  designed  for  IIS  programming.  Furthermore  it 
is  only  a  moderately  complex  language  (certainly  no  more  difficult 
than  say  PL/1)  that  should  easily  be  within  the  intellectual  grasp 
of  an  IIS  programmer  who  should,  in  our  opinion,  be  a  reasonably 
well  trained  person. 

BDL*  s  design  philosophy  sacrifices  flexibility  and  generality 
for  simplicity  and  ease  of  use.  TAXIS,  by  allowing  a  multiplicity 
of  ways  to  program  a  task  has  great  flexibility  and  generality  and 
thus  is  suitable  for  a  wide  range  of  IIS  applications  (including 
office  procedures) .  BDL,  on  the  other  hand,  is  suitable  only  for  a 
restricted  range  of  business  data  processing  problems.  If  we 
desire,  we  can  incorporate  BDL’s  simplicity  and  ease  of  use  into 
TAXIS  programming,  while  maintaining  flexibility  and  generality,  by 
making  predefined  packages  of  TAXIS  class  definitions  available  to  a 
programmer  who  would  only  use  these  class  definitions  to  build  a 
system.  In  this  way,  we  could  provide  a  TAXIS  program  with  the 
style  and  structure  that  is  built  in  to  BDL  programs.  Different 
predefined  TAXIS  packages  could  be  made  available  for  different 
applications  areas,  thus  maintaining  TAXIS's  generality  and 
flexibility. 

5.4  Natural  Language  Front  Ends  to  Database  Systems 

In  this  section  we  survey  three  front  end  systems,  emphasizing 
the  types  of  dialogue  these  systems  support,  rather  than  their 
parsing  techniques  or  knowledge  representation  techniques.  These 
three  systems  were  chosen  because  of  their  robustness  in  accepting 
natural  language  inputs.  We  see  a  natural  language  facility  for 
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TAXIS  as  the  most  desirable  input/output  facility.  Natural  language 
expression  of  gueries  allow  naive  users  to  compose  very  complicated 
questions  with  ease.  Other  input/output  facilities,  such  as  menu 
selection  with  a  light  pen  or  special  purpose  data  languages,  either 
make  it  difficult  to  pose  a  sufficient  range  of  questions  in  a 
natural  way  or  reguire  extensive  training. 

iLsJiJ.  RENDEZVOUS  VERSION  } 

Prehaps  one  of  the  most  sophisticated  natural  language  front 
ends  to  a  database  in  existence  today  is  the  RENDEZVOUS  system 
developed  by  Codd  and  others  [Codd  et  al  78].  This  system  allows  a 
user  to  express  his  queries  as  an  English  sentence  and  can  engage 
the  user  in  a  large  variety  of  dialogues  depending  on  the  contents 
of  his  query.  For  example,  the  system  engages  the  user  in 
clarification  dialogue  when  it  encounters  something  in  his  query 
that  it  does  not  ’’understand ”.  Before  executing  a  retrieval  on  the 
database,  the  system  presents  the  user  with  an  English  restatement 
of  the  systems  version  of  his  query  for  his  approval.  If  the  user 
wishes  to,  he  can  engage  in  dialogue  to  change  either  the  system's 
version  of  his  query  or  his  original  query. 

There  are  eight  major  components  in  RENDEZVOUS.  The  first 
component  is  called  the  analyser.  Its  primary  function  is  to 
translate  the  user's  query  into  DEDUCE,  a  relational  database 
sublanguage.  It  supports  two  types  of  dialogue.  Clarification 
dialogue  consists  of  asking  the  user  questions  about  the  parts  (or 
all)  of  his  query  that  the  system  does  not  understand.  Continuation 
dialogue  allows  the  user  to  build  a  new  query  by  specifying  changes 
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to  the  preceding  query.  The  second  component  is  the  menu- driver, 
which  tests  the  analyser  output  for  logical  correctness.  it  will 
conduct  a  menu-driven  dialogue  in  an  attempt  to  produce  a  logically 
complete  guery  if  the  analyser* s  output  is  logically  incomplete. 
This  dialogue  is  different  from  clarification  dialogue  in  that  the 
dialogue  is  conducted  without  reference  to  the  user's  English 
language  guery.  If  the  analyser's  output  is  logically  complete, 
this  component  will  not  engage  in  any  dialogue.  Note  that  the 
analyser's  output  can  be  empty  as  a  result  of  either  a  user  null 
guery  or  a  complete  failure  of  the  analyser  to  translate  any  part  of 
the  user's  query  into  DEDUCE.  In  this  case  the  menu-driver  conducts 
a  menu-driven  dialogue  with  the  user  to  build  his  guery  from 
scratch.  The  third  component  of  RENDEZVOUS,  the  generator,  performs 
verification  dialogue.  That  is,  the  logically  complete  query  output 
by  the  menu-driver,  is  restated  in  English  for  the  user's  approval. 
If  the  user  approves  the  system's  understanding  of  his  query,  the 
fourth  component  of  RENDEZVOUS,  the  data  retriever  is  activated  and 
gets  the  data  needed  from  the  database  needed  to  answer  the  query. 
It  conducts  output  dialogue  using  the  result  of  the  database 
retrieval.  This  dialogue  is  quite  sophisticated  in  that  it  can 
explain  its  answers  in  certain  cases.  For  instance,  the  system  can 
explain  null  answers  (i.e.  when  the  relation  containing  the  answer 
is  empty)  by  giving  the  user  one  or  more  reasons  for  this. 
RENDEZVOUS  presently  supports  two  types  of  reasons.  The  first  type 
explains  which  simple  qualification  conditions  in  the  guery  yielded 
empty  result  relations.  The  second  type  explains  which  arguments  of 
joins  (on  relations  in  the  database)  have  themselves  yielded  empty 
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result  relations  (even  though  none  of  their  simple  qualifications 
did).  This  explanation  of  what  caused  the  failure  of  his  query  can 
help  the  user  formulate  more  successful  queries  in  the  future.  If 
the  user  disapproves  of  the  system* s  restatement  of  his  query  as 
posed  by  the  generator,  the  user  has  the  option  of  entering  a  new 
guery  (thus  re-invoking  the  analyser)  or  invoking  the  fifth 
component  of  RENDEZVOUS,  the  guery  editor.  This  component  also  uses 
a  menu-driven  dialogue  as  a  means  for  the  user  to  edit  either  his 
query  or  the  system's  version  of  it.  This  type  of  dialogue  is  used 
so  that  the  user  does  not  have  to  learn  editing  commands.  The 
edited  query  is  then  passed  back  to  the  analyser  to  be  processed. 
The  sixth  component  of  RENDEZVOUS  is  called  the  helper.  It  can  be 
activated  at  any  time  the  system  is  requesting  input  from  the  user. 
The  helper  can  be  used  to  gain  information  about  the  database,  get 
help  with  the  keyboard,  invoke  the  query  editor,,  drop  the  current 
guery  and  enter  a  new  one,  resume  the  processing  of  the  current 
guery,  and  end  the  current  session  with  RENDEZVOUS.  This  component 
can  be  particularly  useful  when,  as  a  result  of  all  the  information 
supplied  during  the  clarification  and  menu-driven  dialogues,  the 
user  sees  a  better  and  more  concise  way  to  formulate  his  guery.  The 
seventh  component  of  RENDEZVOUS  is  the  display  support.  This 
component  partitions  the  user's  screen  and  keeps  a  history  of  all 
the  dialogue  interactions  between  the  user  and  the  system.  This 
history  may  be  scrolled  vertically  by  using  special  keys  on  a 
modified  IBM  3277  display  terminal.  The  eighth  and  last  component 
of  RENDEZVOUS  is  the  supervisor.  This  component  invokes  all  other 
components  (except  the  display  support)  as  needed.  The  order  in 
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which  the  supervisor  invokes  the  various  components  is  as  described 
above.  The  supervisor  is  used  to  logon  a  user  and  get  his  initial 
guery.  Once  this  query  has  been  answered  [with  the  supervisor 
invoking  the  necessary  components,  starting  with  the  analyser)  the 
supervisor  asks  whether  the  next  guery  is  a  modification  of  the 
previous  one.  If  it  is,  the  supervisor  instructs  the  analyser  to 
engage  in  continuation  dialogue;  otherwise  the  whole  guery 
evaluation  process  is  started  again. 

The  RENDEZVOUS  system  has  proved  to  be  quite  robust  in  testing 
[Codd  et  al  78].  It  supports  a  rich  variety  of  dialogue  that 
enables  a  naive  user  to  easily  access  information  from  a  database. 

5^4._2  PLANES 

Another  natural  language  question  answering  system,  that  is  in 
much  the  same  spirit  as  RENDEZVOUS,  is  PLANES  {for  Programmed 
LANgt;age-based  Enguire  System)  [Waltz  78].  This  system  has 
organization  and  capabilities  similar  to  RENDEZVOUS.  Processing  of 
a  user  query  is  accomplished  in  four  major  components  or  steps.  The 
first  step  involves  parsing  the  user  input  into  an  internal  form 
{which  can  be  fed  back  to  the  user  or  suppressed) .  The  second  step 
is  translation  of  the  internal  query  form  into  a  formal  query 
expression  (in  the  database  sublanguage  ALPHA)  that  can  be  executed 
on  the  database.  Once  the  formal  guery  has  been  generated,  the 
paraphrase  generator  uses  it  to  construct  an  English  restatement  of 
the  system's  understanding  of  the  user's  guery  for  his  approval. 
The  user  has  the  option  of  changing  parts  of  it  or  entering  a  new 
guery  (if  the  system's  understanding  is  totally  wrong).  The  third 
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step  is  to  execute  the  user  approved  formal  query  produced  by  the 
second  step.  PLANES  exhibits  two  interseting  features  in  this 
regard.  Eirst  it  uses  statistics  to  optimize  the  database  search 
and  second  it  has  an  algorithm  for  deciding  when  to  save  the  results 
of  searchs  for  future  use  (i.e.  an  interesting  result  may  cause  the 
user  to  execute  follow-up  queries) .  Finally  once  the  necessary  data 
to  answer  the  user’s  query  has  been  retrieved,  the  fourth  step  (the 
response  generator)  has  to  decide  the  appropriate  output  format.  If 
at  all  possible,  a  graph  will  be  output;  if  a  graph  is  not  possible 
the  system  will  provide  either  a  list  or  a  table. 

PLANES  supports  many  types  of  dialogue.  Menu  dialogue  is  used 
for  correcting  spelling  mistakes.  Verification  dialogue  is  used  to 
restate  the  system’s  version  of  a  user’s  query  in  English  for  his 
approval.  PLANES  also  uses  clarification  dialogue  to  ask  questions 
about  parts  of  a  query  that  it  doesn't  understand,  to  supply  the 
user  information  about  its  knowledge  and  capabilities,  and  to 
provide  him  with  help  (through  a  HELP  file)  in  the  event  of  errors 
or  a  direct  request  for  help.  A  large  variety  of  requests  can  be 
handled  by  PLANES  including  requests  with  such  things  as  relative, 
comparative,  and  compound  clauses  in  them.  PLANES  can  also  handle 
requests  with  exception  statements  and  user  definitions  of  terms. 
To  edit  a  paraphrase  of  the  system's  version  of  a  query  or  to 
conduct  continuation  dialogue,  PLANES  uses  its  ellipsis  mechanism. 
For  example,  to  change  a  value  of  a  field  in  a  system  paraphrase  of 
a  user  query  the  user  just  types  the  new  value  of  the  field  (as  his 
new  query)  and  the  ellipsis  mechanism  then  produces  the  rest  of  the 
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5.  4.  3  LIFER 

The  last  natural  language  system  discussed  in  this  chapter  is 
called  LIFER  (for  Language  Interface  Facility  with  Ellipsis  and 
Recursion)  [Hendrix  77  and  78  ].  LIFER  is  composed  of  a  set  of 
interactive  language  specification  functions  and  a  parser.  The 
language  specification  functions  are  used  to  define  a  natural 
language  application  language  to  interface  with  some  existing 
software.  The  parser  uses  these  language  specifications  to 
translate  natural  language  input  into  the  appropriate  software 
interactions.  The  LIFER  parser  handles  elliptical  input,  has  a 
spelling  corrector,  and  allows  the  user  to  extend  the  natural 
language  at  run  time.  LADDER,  a  system  for  accessing  large 
distributed  databases,  has  its  first  component,  called  INLAND  (for 
Informal  Natural  Language  Access  to  Navy  Data) ,  implemented  using 
LIFER.  INLAND  accepts  guestions  in  a  restricted  subset  of  English 
and  produces  one  or  more  gueries.  These  queries  are  passed  to  the 
second  component  of  LADDER,  which  is  called  IDA  (for  Intelligent 
Data  Access) .  IDA  creates  the  relevent  DATALANGOAGE  gueries  by 
inserting  the  appropriate  fields  and  file  names  int c  prestored 
templates.  Because  the  database  is  distributed,  only  generic  files, 
rather  than  specific  files,  are  refered  to  in  the  DATALANGOAGE 
guery.  The  third  component  of  LADDER,  FAM  (for  File  Access  Manger) 
finds  the  location  of  these  generic  files  and  accesses  them  to 
produce  an  answer  to  the  user*s  guery. 

INLAND  does  not  support  as  wide  a  variety  of  dialogues  as  does 
RENDEZVOUS  or  PLANES.  For  example,  it  does  not  present  a 
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restatement  of  the  user’s  guery  for  his  approval.  It  does,  however, 
print  error  messages  to  indicate  how  much  of  the  user’s  guery  has 
teen  understood  and  suggests  ways  of  completing  the  query.  INLAND 
also  has  the  capacity  for  a  user  to  extend  the  language  itself  using 
natural  language  commands.  It  does  support  comtinuation  and  editing 
dialogues  in  the  sense  that  it  can  perform  ellipsis  (as  in  PLANES). 

5.4.4  Comments 

Of  the  three  systems,  RENDEZVOUS  provides  the  most 
sophisticated  dialogues.  However,  RENDEZVOUS  (and  also  PLANES  and 
LIFER)  are  incredibly  domain  dependent:  all  their  dialogues  are 
built  on  knowning  the  basic  relations  of  their  respective  databases. 
TAXIS,  on  the  other  hand,  is  domain  independent  in  that  it  offers  a 
system  designer  complete  freedom  as  to  what  types  of  dialogue  he  can 
employee  for  system/user  interaction  in  the  system  he  is  designing. 
A  complete  TAXIS  will  also  include  a  linguistic  component  that  will 
allow  the  system  designer  to  choose  the  syntactic  form  of 
input/output  (as  LIFER  now  does).  As  an  example  of  the  types  of 
dialogue  TAXIS  can  model,  consider  APNs  for  modelling  the 
continuation,  clarification,  verification,  and  menu-driven  dialogues 
exhibited  by  RENDEZVOUS. 

Continuation  dialogue  would  be  conducted  in  a  script  that 
continually  returns  flight  information  from  the  FLIGHT  relation  (see 
Appendix  1  and  Chapter  2)  for  different  sets  of  flight  numbers  and 
dates.  Such  a  script  could  be  used  by  a  travel  agent  to  find  a 
suitable  flight  for  a  passenger.  Once  such  a  flight  has  been  found 
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the  ACQUIRE-TICKET  script  would  be  used  to  make  a  reservation  for 
that  flight  and  monitor  the  purchase  of  the  ticket.  The  script 
could  also  be  used  to  find  new  flights  when  a  desired  flight  is 
filled.  A  possible  APN  for  this  script  is  shown  in  figure  5-A. 
Cnee  one  retrieval  of  flight  information  has  been  made,  the  user  can 
input  a  new  flight  number  and  date,  just  a  new  flight  number,  just  a 
new  date,  or  an  indication  that  no  more  flight  information  is 
reguired.  If  just  a  flight  number  or  date  is  input,  the  previous 
date  or  flight  number  is  reused.  The  state  and  transition  names  in 
the  APN  of  figure  5-A  are  self-explanatory. 

As  an  example  of  clarification  and  verification  dialogues, 
consider  an  APN  to  input  and  validate  a  flight  number  and  date. 
Such  an  APN,  shown  in  figure  5-E,  could  be  made  part  of  the 
ACQUIRE-TICKET  script  (as  mentioned  in  chapter  2) .  Clarification 
dialogue  is  conducted  if  an  invalid  flight  number  or  date  is  input 
or  if  a  validated  flight  number  and  date  pair  do  not  identify  an 
existing  flight.  Verification  dialogue  is  conducted  by  echoing  the 
validated  flight  number  and  date  values  for  user  approval.  The  user 
has  the  option  of  rejecting  any  combination  of  the  two  values;  with 
only  rejected  values  having  to  be  replaced.  Any  replaced  values 
have  to  be  validated  again.  As  before,  the  APN  state  and  transition 
names  are  self-explanatory. 

Finally,  as  an  example  of  a  menu-driven  dialogue,  we  present  an 
APN  in  figure  5-C  for  obtaining  personal  data  (namely  phone  numbers, 
codes,  and  ages)  of  referees,  editors,  and  authors.  This  tree-like 
APN  uses  token  feedback  to  model  multiple  choice  selection.  A  user 
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can  chose  to  receive  personnal  data  about  any  combination  of  one 
referee,  one  editor,  and  one  author.  All  choices  made  are 
completely  evaluated  one  at  a  time  in  random  order.  First  the 
appropriate  name  and  address  keys  (i.e.  name  and  address  are  the 
keys  of  variable  classes  REFEREE,  EDITOR,  and  EDITOR)  must  be  input. 
Then  the  user  can  decide  to  receive  any  combination  of  a  phone 
number,  a  code,  and  an  age.  Once  a  particular  choice  has  been 
evaluated,  the  next  unprocessed  choice  (if  any)  is  evaluated.  As  it 
is  now  designed,  the  APN  can  supply  only  three  sets  of  data  at  most; 
with  a  set  of  data  corresponding  to  each  of  a  referee,  an  editor, 
and  an  author  respectively.  However,  it  can  easily  be  modified  to 
conduct  continuation  dialogue. 
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Conclusion 


6. X  Concluding  Remarks 

This  thesis  has  incorporated  script  and  transition  classes  into 
TAXIS  using  the  existing  framework  of  properties,  classes,  and  the 
IS-A  hierarchy.  These  two  new  built-in  metaclasses  constitute  the 
pragmatic  component  of  TAXIS.  The  modified  APN  formalism  adopted 
from  [ Zisman  77  and  78]  has  proven  to  be  a  good  graphical  tool  for 
modelling  IISs.  This  is  because  an  APN  gives  an  IIS  programmer  an 
overall  view  of  an  independent  logical  component  of  an  IIS  without 
concerning  him  with  the  details  associated  with  each  transition  in 
the  APN.  The  direct  translation  of  the  APN  into  a  corresponding 
script  allows  the  IIS  programmer  to  concern  himself  with  the  details 
of  each  transition  without  bothering  with  the  overall  organization 
of  the  APN.  Further  evidence  that  scripts  have  been  incorporated 
into  the  TAXIS  framework  can  be  seen  from  the  fact  that  scripts  (and 
transitions)  can  be  specialized  under  a  set  of  IS-A  constraints  in 
the  same  manner  as  all  other  TAXIS  classes.  Also  the  TAXIS  program 
design  methodology  has  been  successfully  extended  to  include 
scripts. 

The  IIS  examples  illustrated  in  this  thesis  show  that  scripts 
are  suitable  for  modelling  the  organizational  and  structural 
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requirements  of  some  IISs  in  general.  The  dialogue  commands  and 
predicates  have  proved  sufficient  in  providing  the  necessary 
dialogue  capability,  in  that  not  only  can  information  be  input  or 
output  by  either  the  user  or  the  IIS  but  that  the  IIS  can  also  ask 
the  user  to  perform  actions.  The  journal  editing  example  of 
Chapter  4  demonstrated  the  capability  of  the  I/O  commands  and 
predicates  for  satisfying  communication  and  coordination 
requirements  of  concurrently  running  scripts.  The  APN  figures  of 
Chapter  6  present  evidence  that  TAXIS  can  model  the  various  type  of 
dialogues  exhibited  by  systems  with  sophisticated  natural  language 
front  ends. 

Some  problems  still  exist  in  using  APNs  to  model  IISs.  One 
problem  is  that  Petri  nets  become  extremely  complex  when  only  a 
moderate  increase  is  made  in  system  size.  For  example,  to  add 
semantic  integrity  checking  to  all  input  data  items  in  the 
ACQUIRE-TICKET  script  of  Chapter  2  would  require  a  much  more 
complicated  APN  then  presented  there.  (Figure  5-B  illustrates  the 
complexity  that  can  arise  from  simple  semantic  integrity  checking). 
We  can  reduce  this  complexity  by  having  separate  APNs  handle  the 
task  of  obtaining  new  data  values  in  the  event  of  invalid  input. 
Scripts  corresponding  to  these  APNs  could  be  executed  by  either 
being  raised  as  the  result  of  some  failed  postregs  condition  in  a 
main  script  acquiring  the  data  or  instantiated  by  the  main  script 
with  I/O  commands  and  predicates  being  used  to  transfer  the  new  data 
values  and  provide  the  required  synchronization.  Also,  as  suggested 
by  [Gibbs  80],  the  complexity  of  APNs  can  be  reduced  by  making  them 
logic  independent.  Thus,  for  example,  figure  2-B  (i.e.  the  APN  for 
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making  an  airline  reservation  in  the  ACQUIRE-TICKET  script)  can  be 
significantly  reduced  by  incorporating  the  five  data  gathering 
transitions  into  one  single  transition.  Another  problem  in  using 
Petri  nets  is  their  inability  to  graphically  represent  the  NOT 
condition,  although  scripts  can  encode  this  type  of  condition  (see 
Chapter  3.2.2).  We  can  overcome  this  drawback  by  adopting  inhibitor 
arcs  into  Petri  nets  as  proposed  by  [Peterson  77]. 

Finally,  one  last  problem,  associated  with  scripts  in  general, 
is  the  inability  of  users  to  input  unreguested  (i.e.  unexpected) 
data.  That  is,  no  way  exists  to  interrupt  a  script's  execution  and 
change  data  values  previously  input  and  verified,  even  though  not 
having  this  information  can  "hurt"  the  integrity  of  a  script's 
execution  (as  transitions  that  use  these  data  values  may  now  execute 
and  fire  incorrectly) .  For  example,  while  a  change  in  a  passenger's 
address  and  phone  number  would  not  affect  the  integrity  of  an 
instance  of  ACQUIRE-TICKET  monitoring  that  particular  ticket 
purchase,  a  change  in  a  flight's  date  would  destroy  the  integrity  of 
all  ACQUIRE-TICKET  instances  monitoring  ticket  purchases  on  that 
flight  (as  these  instances  would  now  be  using  an  incorrect  date 
value  in  the  execution  and  firing  of  some  of  their  transitions) .  A 
solution  to  this  problem  may  involve  the  design  of  new  dialogue 
commands  and  a  script  interruption  mechanism  for  restoring  the 
integrity  of  scripts  when  interrupted  by  these  commands.  This 
problem  requires  further  work. 

The  design  of  the  pragmatic  component  of  TAXIS  is  not  complete 
in  the  sense  that  some  refinements  may  be  made.  For  example,  the 
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number  of  dialogue  predicates  available  may  be  reduced.  Also  the 
syntax  presented  in  Chapter  3  and  used  throughout  this  thesis  may 
change;  indeed  the  syntax  of  the  semantic  component  has  already 
undergone  many  changes.  However  the  semantics  of  TAXIS  scripts  and 
transitions  should  remain  the  same. 

6^2  Future  Ee search 

The  work  described  in  this  thesis  constitutes  only  a  part  of 
the  TAXIS  project.  Scripts,  via  the  APN  representation  developed  in 
this  thesis,  provide  facilities  for  the  definition  of  the  pragmatic 
aspects  of  a  user  interface  for  an  IIS.  The  syntactic  (i.e. 
linguistic)  aspects  of  a  user  interface  (which  would  be  used  to 
specify  the  actual  form  of  I/O  messages)  has  yet  to  be  designed.  He 
see  this  component  being  added  to  TAXIS  within  the  existing 
framework  of  properties,  classes,  and  the  IS-A  hierarchy.  Once  the 
design  of  TAXIS  is  complete,  a  TAXIS  parser  and  compiler  should  be 
written  to  test  the  language.  Such  an  implementation  would  involve 
the  solution  of  such  theoretical  problems  as  the  mapping  of  IS-A 
hierarchies  of  data,  transaction,  and  script  classes  into  relations, 
procedures,  and  production  systems  respectively.  Finally,  to  study 
the  usefullness  of  TAXIS  to  particular  application  areas,  we  wish  to 
explore  the  possibility  of  extending  TAXIS  to  make  it  suitable  for 
one  type  of  application  area,  say  a  payroll  or  an  inventory  control 
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Overview  of  TAXIS  Semantics 


This  appendix  gives  a  brief  introduction  to  the  semantics  of 

TAXIS.  It  is  based  on  the  more  detailed  presentations  found  in 

[Mylopoulos  et  al  78a,  78b,  and  79]  and  [Wong  80].  All  examples 
were  freely  borrowed  from  these  references  (with  modifications  made 
where  necessary)  and  the  reader  is  referred  to  them  for  more 
information. 

A  TAXIS  program  is  viewed  as  a  collection  of  classes,  organized 
into  an  IS-A  hierarchy.  If  class  A  is  IS-A  class  B  then  A  has  at 

least  the  properties  of  B  plus  properties  that  can  be  new  or 

specializations  of  existing  properties  of  B.  TAXIS  properties  are 
triplets  consisting  of  one  or  more  subjects,  an  attribute  (or 
property  name),  and  a  property  value  (abbrev.  p-value) .  There  are 
three  types  of  objects  in  TAXIS:  tokens  (i.e.  constants),  classes 
(i.e.  collections  of  tokens  sharing  common  characteristics)  and 
metaclasses  (i.e.  collections  of  classes  sharing  common 
characteristics).  In  general  any  information  that  one  wishes  to 
associate  with  an  object  has  to  be  represented  in  terms  of 
properties.  TAXIS  has  property  categories  to  distinguish  between 
properties  used  to  express  different  aspects  of  an  object's 
structure  and/or  behavior.  For  example  a  relation  may  have  keys. 
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characteristics,  and  attribute  property  categories  while  a 
transaction  (i.e.  a  procedure)  may  have  parameters,  local 
declarations,  values  returned,  prerequisite  {i.e.  preconditions), 
actions,  and  postregs  (i.e.  postconditions)  property  categories. 
If  a  property  has  only  one  subject  it  is  a  simple  property; 
otherwise  it  is  a  complex  property.  If  a  property  represents 
information  about  their  subject (s)  they  are  called  definitional 
properties  (i.e.  properties).  If  a  property  represents  information 
about  instances  of  their  subjects  they  are  called  factual  properties 
(i.e.  facts)  .  To  allow  traversal  of  the  schema  defined  within  a 
TAXIS  program  by  its  classes  and  their  definitional  properties  we 
have  a  "schema  selector"  denoted  by  .  Thus  PERSON.. age  returns 

the  class  AGE-VALUE  if  PERSON  is  the  subject  of  a  property  with 
attribute  age  and  p-value  the  class  AGE-VALUE.  Similarly  to  obtain 
values  of  factual  properties  we  have  the  ". "  operator.  Thus 
john-smith. age  might  return  32  if  john-smith  is  an  instance  of 
PERSON  and  32  is  an  instance  of  AGE-VALUE. 

The  main  metaclasses  (i.e.  types  of  classes)  that  make  up  the 
semantic  part  of  TAXIS  are: 

1)  variable  classes 

2)  aggregate  classes 

3)  finitely  defined  classes 

4)  formatted  classes 

5)  transaction  classes 

6)  expression  classes 

7)  exception  classes 
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8)  test  defined  classes 

The  first  four  classes  will  be  referred  to  as  the  data  classes. 

The  most  important  type  of  data  class  is  that  of  VARIABLE-CLASS 
which  has  many  of  the  features  of  relations.  A  relational  database 
is  advocated  for  TAXIS  (i.e.  to  be  built  directly  into  the 
language)  because  of  its  simplicity,  its  high  degree  of  data 
independence,  the  ease  with  which  database  problems  can  be 
formulated  in  percise  mathematical  terms,  and  the  small  yet  powerful 
languages  that  can  be  developed  around  it.  TAXIS  variable  classes 
have  ’keys',  'characteristics'  and  'attributes'  property  categories. 
The  'keys'  property  uniguely  identifies  tuples  in  a  relation.  The 
'characteristics'  and  'attributes'  properties  are  non-key  fields 
with  the  distinction  being  that  the  p-value  of  a  'characteristics' 
property  cannot  be  changed  while  the  p-value  of  an  'attributes' 
property  can  be  changed. 

Variable  classes  support  two  types  of  abstraction;  aggregation 
and  specialization.  Aggregation  (which  is  commonly  used  in  database 
design)  refers  to  an  abstraction  in  which  relationships  between 
objects  is  regarded  as  a  higher  level  object  (i.e.  a  relationship 
between  a  person,  a  hotel,  and  a  date  can  be  thought  of  as  a 
reservation) .  Specialization  refers  to  an  abstraction  in  which  a 
set  of  similar  objects  is  regarded  as  a  generic  object  (i.e.  a  set 
of  employed  people  can  be  abstracted  as  the  generic  object  employee 
or,  in  other  words,  an  employee  can  be  abstracted  to  specialized 
objects  such  as  trucker,  engineer,  etc.).  Both  aggregation  and 
specialization  of  data  classes  are  used  within  TAXIS  programs.  That 
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is,  data  classes  within  a  TAXIS  program  should  be  structured  as  a 
set  of  aggregation  hierarchies  intersecting  with  an  orthogonal  set 
of  specialization  hierarchies  (i. e.  as  proposed  in  [Smith  and  Smith 
76]).  As  an  example  of  a  variable  class  consider  a  relation 
containing  flight  information. 


VARIAELE-CLASS  FLIGHT  jrith 
keys 

flight:  (flight#, date)  ; 
characteristics 

flight#:  {| 1  : :999 1}  ; 

departure:  [|city:CTTY,  c ountry :COUNTRY |  ] ; 
destination:  LOCATION; 
date:  DATE-VALUE; 
time:  TIME-VALUE; 
attributes 

seats-lef t :  NON-NEGATIVE-INTEGER; 
ticket-cost:  MONEY-VALUE; 

end 


AGGREGATE-CLASS  LOCATION  with 
Mis 

location:  (city, country)  ; 
characteristics 

city:  CITY; 
country:  COUNTRY; 

end 


The  data  class  defined  by  {|1::999|}  is  called  a  f initely- defined 
class.  It  is  a  finite  time- invariant  collection  of  instances  which 
includes  all  integers  from  1  to  999.  The  data  class  defined  by 
[ |city:CITY,  country: COUNTRY |  ]  is  an  instance  of  the  metaclass 
AGGREGATE-CLASS.  It  has  as  instances  all  two-tuples  with  first 
component  an  instance  of  CITY  and  second  component  an  instance  of 
COUNTRY.  The  class  LOCATION  illustrates  a  second  way  of  defining 
the  aggregate  class  [|city:CITY,  country: COUNTRY | ] .  However  one 
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difference  exists:  if  both  FLIGHT .. depart ure  and 
FLIGHT. . destination  were  defined  as  LOCATION  then  FLIGHT .. de part ure 
eguals  FLIGHT. . destination  but  if  one  or  both  of  FLIGHT . .de part ure 
and  FLIGHT. . destination  were  defined  as 
[ |city:CITY,  country: COUNTRY|  ]  then  the  equality  does  not  hold. 
This  is  because  each  class  definition  that  appears  in  a  TAXIS 
program  causes  the  introduction  of  yet  another  class  into  the  schema 
described  by  the  program.  The  data  classes  DATE-VALUE,  TIME-VALUE, 
and  MONEY-VALUE  could  be  formatted  classes  in  that  they  specify  the 
reguired  forms  of  a  date,  a  time,  or  a  money  value.  For  example,  a 
date  value  could  be  defined  as: 


FORM  A TTED -CLASS  DATE-VALUE  with 
REPEAT  (DIGIT,  2)  5)  {!  •/•  |}  5) 
REPEAT  (DIGIT, 2)  5>{|  »/*  1}  3) 
REPEAT  (DIGIT, 2)  ; 


which  means  the  date  has  form  dd/dd/dd  where  d  is  a  digit.  Finally, 
NON-NEGATIVE-INTEGER  might  be  a  test-defined  class  in  that  only 
positive  integers  and  zero  can  be  instances  of  it  (more  on  it 
later) .  Now  we  present  two  specializations  of  FLIGHT,  namely 
INTERNATIONAL-FLIGHT  and  FL IG HT-W ITHIN-CANADA . 


VARIABLE-CLASS  INTERNATIONAL- FLIGHT  isa  FLIGHT  with 
keys 

international-flight:  (flight#, date) ; 
characteristics 

flight#:  INTERNATIONAL-FLIGHT#; 
first-class-seats:  INTEGER; 

end 


V ARIA ELE- CLASS  FLIGHT-WITHIN-CANADA  isa  FLIGHT  with 
keys 

f ligh t-within-canada :  (flight #, date) ; 
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characteristics 

flight#:  FLIGHT#- WITH IN-CAN AD A ; 

departure:  [  J count ry: CANADA | ]  isa  FLIGHT. . departure ; 
destination:  INTEF.NAL-LOCATION ; 

end 


INTER  NATIONAL-FLIGHT#  :=  {J500::999|}  isa  FLIGHT. . flight # : 


FLIGHT#-WITHIN-CANADA  :=  {|  1 :  : 499  | }  isa  FLIGHT. . flight# ; 


CANADA  :=  { | *  CANADA  * | }  isa  COUNTRY; 


AGGREGATE-CLASS  INTERNAL-LOCATION  isa  LOCATION  with 
keys 

internal-location:  (city, country)  ; 
characteristics 
country:  CANADA; 


The  variable  classes  INTERNATIONAL-FLIGHT  and 
FLIGHT-WITHIN-CAN ADA  are  specializations  of  the  variable  class 
FLIGHT.  As  such,  they  inherit  intact  all  properties  of  FLIGHT  not 
new  or  specialized.  For  example,  both  classes  inherit  the  date, 
time,  seats-left,  and  ticket-cost  properties  of  FLIGHT.  We  have 
specialized  the  f initely-f ormed  class  (|1::999J)  in  both 
INTERNATIONAL-FLIGHT#  and  FLIGHT#-WITHIN-CANADA  to  be  subclasses  of 
{|  1::  999|}  with  the  ranges  500::999  and  1::499  respectively. 
CANADA:={| 'CANADA* |}  isa  COUNTRY  makes  CANADA  a  class  with  a  single 
instance  (i.e.  COUNTRY  has  many  instances  such  as  'USA',  'GREECE', 
etc.  in  addition  to  'CANADA').  The  "departure"  and  "destination" 
properties  of  FLIGHT# -WITHIN- CAN A DA  illustrate  two  different  ways  of 
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specializing  aggregate  classes.  Since  the  aggregate  class  defined 
ty  [  | country : CAN ADA |  ]  is  a  specialization  of  FLIGHT. . departure  it 
has  two  (not  one)  characteristic  properties  as  "city"  is  inherited. 
Similarily  since  INTERNAL-LOCATION  IS-A  LOCATION ,  INTERN AL-LOC AT  ION 
has  tuples  with  first  component  an  instance  of  CITY  (as  inherited 
from  LOCATION)  and  second  component  an  instance  of  CANADA  (whose 
only  value  is  ’CANADA*)  which  IS-A  COUNTRY.  Finally  we  note  that 
the  property  "first-class-seats"  is  a  new  characteristics  property 
added  to  INTERNATIONAL-FLIGHT  which  is  not  in  FLIGHT.  As  can  be 
seen  from  the  above  example  we  carry  out  specialization  and 
aggregation  in  parallel  using  IS-A  of  properties. 

To  ensure  the  semantic  correctness  of  database  information  and 
to  perform  other  specified  tasks  we  have  transactions  (which  are 
somewhat  similar  to  ordinary  programming  language  procedures)  .  They 
have  *  parameter-list  * ,  'locals',  'preregs',  'actions',  'postregs', 
and  'returns'  property  categories.  They  are  respectively  the 
parameter  list,  the  local  declarations,  the  preconditions  to  be 
checked,  the  actions  to  be  carried  out,  the  postconditions  to  be 
checked  after  the  actions  have  been  carried  out,  and  the  value 
returned.  A  transaction  is  evaluated  in  the  following  way.  First 
the  'preregs9  conditions  are  checked.  If  they  are  satisfied  the 
'actions'  properties  are  carried  out.  These  may  be  insertions, 
deletions,  and  modifications  on  database  entries,  calculations 
involving  data  local  to  the  transaction  and/or  data  from  the 
database,  calls  to  other  transactions,  etc.  These  actions  can  be 
expressed  as  a  series  of  structured  expressions  (i.e.  TAXIS  has 
conditional,  block,  WHILE  and  FOR  statements  as  well  as  relational 
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operations  such  as  retrieve,  insert-object,  delete-object,  etc.  for 
accessing  variable  classes).  Next,  the  'postregs'  conditions  are 
checked  to  ensure  database  integrity.  Finally  if  the  'postregs* 
conditions  are  satisfied  the  ’returns'  property  is  executed.  Each 
property  of  the  'preregs',  'actions',  'postregs'  and  'returns' 
categories  are  instances  of  expression  classes.  That  is,  'preregs' 
and  'postregs'  conditions  are  TAXIS  boolean  expressions  and 
'actions'  and  'returns*  statements  are  TAXIS  non-boolean 
expressions.  The  'returns*  expression  must  evaluate  to  a  single 
value  with  no  side  effects  while  'actions'  expressions,  besides 
evaluating  to  values  can  have  side  effects.  If  a  transaction  is 
called  as  a  subroutine  procedure  (versus  being  called  as  a  function 
procedure)  then  the  value  returned  is  lost.  One  striking  difference 
between  transactions  and  procedures  (in  the  usual  sense)  is  that 
transactions  cannot  have  global  variables  while  procedures  can. 

If  one  of  the  conditions  specified  in  the  'preregs*  or 
'postregs'  property  categories  fails  (i.e.  is  false)  then  a 
specified  exception  is  raised  (if  an  exception  is  not  specified  an 
execution  error  occurs) •  Exceptions  are  metaclasses  similar  to 
PASCAL  records.  That  is  when  a  precondition  or  postcondition  fails 
an  instance  of  the  exception  specified  is  created  (i. e.  raised) 
with  the  appropriate  values  stored.  The  exception  instance  is  used 
as  the  only  'parameter-list'  entry  to  the  exception  handler  (which 
is  another  transaction)  which  tries  to  the  resolve  the  situation 
causing  failure.  Once  it  has,  control  returns  to  the  next  excutable 
statement  in  the  transaction.  The  exception  handler  is  specified  in 
the  caller  of  the  transaction.  The  advantage  of  this  is  that 
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depending  on  who  calls  the  transaction  different  exception  handlers 
may  be  specified  for  the  same  exception.  This  exception  handling 
mechanism  was  adopted  from  [Wasserman  77  and  79]  and  modified  to  fit 
within  the  TAXIS  framework. 

The  specialization  of  expressions  requires  special  IS-A 
constraints.  If  E  and  E*  are  boolean  expressions  then  E  IS-A  E*  if 
E  implies  E *  and  causes  at  least  the  side  effects  caused  by  E*.  If, 
cn  the  other  hand  E  and  E‘  are  non-boolean  expressions  then  E  must 
cause  at  least  the  side  effects  caused  by  E*  for  E  to  be  IS-A  E*. 
For  example  if  boolean  expression  E*  is  X>0  and  boolean  expression  E 
is  X>10  then  E  IS-A  E'  because  X>10  implies  X>0.  If  non-boolean 
expressions  E  and  E‘  are  insert-ob iect  in  Y  with  Y.p< — person  and 
inser t-ob iect  in  Y*  with  Y * . p< — person*  respectively,  then  the 
variable  class  Y  must  be  IS-A  the  variable  class  Y*  {and  of  course 
person  must  be  IS-A  person*)  for  E  to  be  IS-A  E*.  Thus  an  insertion 
into  Y  would  also  be  an  insertion  into  Y*  so  that  executing  E  would 
cause  at  least  the  side  effects  caused  by  E*. 

The  ‘parameter-list*  and  'locals*  properties  of  transaction 
classes  and  the  properties  of  exception  classes  are  specialized  in  a 
similar  fashion  to  the  properties  of  variable  classes  {and  other 
data  classes) . 

An  example  of  how  a  TAXIS  transaction  class  might  be  designed 
to  reserve  seats  is  given  below. 

TRANSACTION-CLASS  RESERVE-SEAT  with 
parameter-list 

reserve-seat:  {p,  f)  ; 
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locals 

p:  PERSON; 
f:  FLIGHT; 
x;  INTEGER; 
preregs 

seats-left?:  f. seats- left>0 ; 
actions 

make- reservation:  insert-obiegt  in  RESERVATION  with 

person  < —  p,  flight  < —  f; 
decrement-seats:  f. seats- left  < —  f . seats-lef t-1 ; 
assign-aux- variables:  x  < —  f. seats-lef t; 
returns 
rtn:  x; 


The  above  definition  sets  up  a  complex  definitional  property 
through  the  parameter  list  property  whose  subjects  are  PERSON  and 
FLIGHT ,  whose  attribute  is  reserve-seat,  and  whose  value  is  the 
transaction  RESERVE-SEAT.  The  •preregs*  property  checks  if  the 
number  of  seats  left  on  the  flight  is  greater  than  0;  if  it  isn*t 
an  error  occurs.  Assuming  it  is,  three  ‘actions*  properties  are 
carried  out.  The  first  ’actions*  property  assumes  that  RESERVATION 
has  been  previously  defined  as  a  variable  class  and  that  it  has  two 
characteristics  with  attributes  person  and  flight  respectively. 
Thus  the  insert-object  statement  inserts  an  instance  into  this 
variable  class  and  sets  its  two  characteristics  properties  to  p  and 
f  respectively.  The  other  two  ’actions*  properties  decrement  the 
seats-lef t  property  of  flight,  f,  by  one  and  set  the  locals  variable 
x  to  be  the  value  returned  by  the  transaction  in  the  returns 
property. 

We  can  specialize  transactions  in  two  ways.  Suppose  we  wish  to 
have  a  constraint  whereby  each  child  must  be  accompanied  by  his  or 
her  guardian  on  an  international  flight.  The  first  way  to  do  this 
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is: 


preregs  accompanied-by-guardian?:  on 

(CHILD, INTERNATIONAL-FLIGHT) . .reserve-seat  is 
[ p. guardian ,f ]  instance-of  RESERVATION; 

This  definition  adds  "accompanied-by-guardian?"  as  a  prerequisite 
property  to  the  (CHILD r INTERNATIONAL-FLIGHT) .. reser ve-seat 

transaction  which,  of  course,  also  inherits  all  the  properties  of 
RESERVE-SEAT.  The  second  way  to  do  this  is: 


TRANSACTION-CLASS  RESERVE-SEAT-CHILD  isa  RESERVE-SEAT  with 
parameter-list 

reserve-seat-child:  (p,f) ; 
locals 

p:  CHILD; 

f:  INTERNATIONAL- FLIGHT; 


preregs 

accompanied-by-guardian? : 


end 


[ p. guardian, f]  instance-of 
RESERVATION; 


The  transaction  RESERVE-SEAT-CHILD  has  the  locals  properties  p  and  f 
specialized  to  be  CHILD  and  INTERN ATIONAL- FLIGHT  (which,  of  course, 
are  IS-A  PERSON  and  FLIGHT  respectively)  .  In  addition  the  preregs 
property  "accompanied-by-guardian?"  is  added.  RES  ERVE -SEAT-CHILD 
inherits  all  other  properties  of  RESERVE-SEAT.  Thus  the 
(CHILD, INTERNATIONAL-FLIGHT) . .reserve-seat  and  RESEPVE-SEAT-CHILD 
transactions  do  the  same  thing.  However  RESERVE- SEAT-CHILD  has  to 
be  called  explicitly  and  its  parameters  must  be  instances  of  CHILD 
and  INTERNATIONAL- FLIGHT  respectively.  On  the  other  hand  if  the 
transaction  RESERVE-SEAT  is  called  with  its  parameters  being 
instances  of  CHILD  and  INTERNATIONAL-FLIGHT  (they  might  of  course  be 
only  instances  of  PERSON  and  FLIGHT)  then  the  preregs  property 
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"accompanied-by-guardian?"  is  associated  with  it  automatically  and 
so  no  explicit  call  has  to  be  made. 

We  can  now  specify  exception  classes  with  the  preregs 
properties  of  the  above  transactions.  As  an  example  consider  the 
preregs  property  "seats-left?"  of  RESERVE-SEAT  and  its  two 
specializations  (CHILD , INTERNATIONAL-FLIGHT) .. reserve-seat  and 
RESERVE-SEAT-CHILD.  First  we  specify  the  appropriate  exception 
classes  to  hold  all  relevant  information  to  deal  with  the  failed 
preregs  property. 

EXCEPTION-CLASS  NO-SEATS-LEFT  wit^i 
attributes 

pers:  PERSON; 
fit:  FLIGHT; 

end 

EXCEPTION-CLASS  NO-S EAT-FOR-C HILD  isa  NO-SEATS-LEFT  with 
attributes 

guardian:  ADULT; 

end 

Note  that  these  two  classes  obey  the  usual  IS-A  constraints.  To 
specify  when  an  exception  should  be  raised  we  associate  with  a 
'preregs*  or  'postregs'  property  an  exception  class.  For 
RESERVE-SEAT  we  can  associate  the  NO-SEATS-LEFT  exception  with  the 
"seats-left?"  property  by  replacing  the  "seats- left?”  property  with 

seats-left?:  f . seats-left>0  exc 

NO-SEATS-LEFT  (pers: p  ,f It : f ) ; 

or  by  adding  a  definitional  property  to  the  p-value  of  the 
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"seats- left?”  property  with 

exception- property  exc  on 

RESERVE- SEAT. . seats -left?  is 
NO-SEATS-LEFT (pers : p ,flt : f )  ; 

In  both  cases  the  associations  "pers:p"  and  "flt:f"  indicate  the 
p-values  to  be  assigned  to  the  factual  properties  of  the 
NC-SEATS-LEFT  instance  when  the  ' prereqs*  property  "seats^lef t?" 
fails.  In  a  similar  fashion  we  can  associate  NO-SEAT-FOR-CHI LD  with 
the  transaction  (CHILD, INTERNATIONAL-FLIGHT)  .. reserve-seat  by 

exception- property  exc  on 

(CHILD, INTERNATIONAL-FLIGHT) . .reserve-seat. .seats-left?  is 
NO-SEAT-FOR-CHILD (pers: p, fit: f , guardian: p. guardian) ; 

We  can  also  associate  NO-SEAT-FOR-CHILD  with  RESERVE-SEAT-CHILD  in 
the  two  ways  shown  for  associating  NO-SEAT-LEFT  with  RESERVE- SEAT . 

As  mentioned  earlier,  if  an  exception  is  raised  in  a 
transaction  an  exception  handler  must  be  specified  in  the  caller  of 
the  transaction.  For  example  to  indicate  that  the  transaction 
FIND- ALTERNATIVE  should  be  called  if  the  exception  NO-SEATS-LEFT  is 
raised  we  write 

TRANSACTION-CLASS  CALLER  with 

•  •  • 

act  ions 

act:  reserve-seat (pi , fl)  exc-handler  eh  for 
NO-SEATS-LEFT  is  FIND- ALTERNATIVE ; 

•  •  • 

end 


Next  we  must  augment  the  exception  handler  FIND-ALTERNATIVE  for  the 
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exception  handling  property  "eh"  of  CALLER.. act  and 
NO-SEAT-FOR-CHILD. 

action  f ind-alternative-f or- guardian- too  on 
(CALLER. .act,  NO-SEAT-FOR-CHILD) . .eh  is 
/*  actions  to  be  performed  */; 

For  the  RESERVE-SEAT-CHILD  transaction  we  can  associate  a 
transaction  FIND-ALTERNATIVE-CHILD  with  each  raised  instance  of 
NO-SEAT-FOR-CHILD  in  its  caller  in  a  similar  manner  to  associating 
FIND- ALTERNATIVE  with  each  raised  instance  of  NO-SEAT-LEFT  in 
CALLER.  FIND-ALTERNATIVE-CHILD  would  perform  the  same  actions  as 
FIND-ALTERNATIVE  and  the  actions  in  the 

" find- alt er native- for-g ua rdia n-too"  p roper ty. 

Aggregate,  finitely-defined  and  formatted  classes  are  all 

special  cases  of  test-defined  classes.  That  is,  such  classes  have 

membership  in  them  determined  by  transactions  defined  for  this 

purpose.  For  example  TEST-AGGREGATE (x,C)  checks  that  the  components 
of  aggregate  x  are  instances  of  the  p-values  of  C*s  attribute 

properties.  Not  all  test  transactions  are  predetermined  as  they  are 
for  aggregate,  finitely-defined  and  formatted  classes.  For  example 
we  can  define  the  metaclass: 

metaclass  POSITIVE-CLASS  isa  TEST-DEFINED-CLASS 

and  then  the  transaction: 

TRANSACTION-CLASS  TEST-POS-INT  isa  TEST-TRANSACTION  with 
par ameter-list 

test-pos-int:  (int, class)  ; 
locals 

int:  INTEGER; 
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class:  POSITIVE-CLASS; 
returns 

rtrn:  (int  >=  0)  ; 
end  TEST-POS-INT; 

thus  setting  up  a  definitional  property  vhose  subjects  are  INTEGER 
and  POSITIVE-CLASS,  whose  attribute  is  test-pos-int,  and  whose  value 
is  TEST-POS-INT.  Now  the  class  defined  by: 

POSITIVE-CLASS  NON-NEGATIVE-INTEGER  isa  INTEGER 


can  only  have  as  instances  all  positive  integers  and  zero. 
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Appendix  B 


Petri  Nets 


This  appendix  presents  a  brief  introduction  to  Petri  nets.  As 
such,  it  only  provides  sufficient  information  about  Petri  nets  so 
that  the  reader  can  understand  the  APN  formalism  described  in  this 
thesis.  More  detailed  presentations  of  Petri  nets  can  be  found  in 
[Bernstein  73],  [Holt  and  Commoner  70],  [Peterson  77],  and  [  Zisman 
77,78  ]. 

A  Petri  net  is  a  directed  graph  with  two  different  types  of 
nodes.  A  node  represented  by  a  circle  is  called  a  state  (actually 
in  the  literature  it  is  called  a  place)  and  a  node  represented  by  a 
bar  is  called  a  transition.  Each  transition  can  have  one  or  more 
input  states  (i.e.  states  that  have  edges  directed  into  the 
transition)  and  one  or  more  output  states  (i.e.  states  that  have 
edges  directed  out  of  the  transition) .  Similarly  each  state  can 
have  one  or  more  input  transitions  (i.e.  transitions  that  have 
edges  directed  into  the  state)  and  one  or  more  output  transitions 
(i.e.  transitions  that  have  edges  directed  out  of  the  state)  .  Each 
state  (i.e.  place)  of  a  Petri  net  can  hold  one  or  more  tokens  (each 
represented  by  a  black  dot).  If  all  the  input  states  for  a 
transition  contain  at  least  one  token  then  the  transition  is  said  to 
be  "enabled”.  An  enabled  transition  may  "fire".  The  firing  of  an 
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enabled  transition  removes  a  token  from  each  input  state  and  places 
a  token  in  each  output  state-  This  will  most  likely  "disenable"  the 
transition  as  all  of  its  input  states  will  most  likely  not  have 
tokens  in  them  (unless  the  input  states  are  a  subset  of  the  output 
states  or  have  several  tokens  in  them). 

Petri  nets  can  be  used  to  model  concurrency,  synchronization, 
and  decision  making.  Concurrency  is  provided  by  the  ability  for  a 
transition  to  have  multiple  output  states.  As  such  it  is  analogous 
to  the  "fork"  operation  in  parallel  programming  languages.  An 
example  of  concurrency  is  given  in  figure  B-1.  If  a  token  is  placed 
in  state  Si  then  the  transition  T1  is  enabled.  If  T1  should  fire 
then  tokens  will  be  placed  in  each  of  S2,  S3,  and  S4  (and,  of 
course,  a  token  will  be  removed  from  Si)  .  At  this  time  transitions 
T2,  T3,  and  T4  are  enabled  and  can  fire.  These  transitions  can  fire 
in  a  nondeterministic  way  and  it  is  possible  that  at  some  later  time 
tokens  can  exist  in  each  of  S5,  S6,  and  S7.  In  that  case  we  have 
represented  concurrency  of  the  occurrence  of  three  tasks  represented 
by  the  firing  of  T2,  T3,  and  T4.  The  occurrence  of  these  tasks  is 
independent  of  each  other  and  so  they  are  asynchronous  in  nature. 

Synchronization  is  provided  by  the  ability  for  a  transition  to 
have  multiple  input  states.  As  such  it  is  analogous  to  the  "join" 
operation  of  parallel  programming  languages.  An  example  of 
synchronization  using  Petri  nets  is  given  in  figure  B-2.  Transition 
T4  cannot  fire  until  each  of  states  Si,  S2,  and  S3  have  a  token  in 
them.  These  states  cannot  have  tokens  in  them  until  each  of 
transitions  T1,  T2,  and  T3  have  fired.  The  firing  of  these 
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transitions  represents  the  termination  of  three  events.  This 
configuration  could  be  used  to  synchronize  the  completion  of  the 
three  tasks  of  figure  B-1. 

Decision  making  is  represented  by  the  ability  of  a  state  to 
have  multiple  output  transitions.  An  example  of  decision  making  is 
given  in  figure  B-3.  If  Si  has  a  token  in  it  then  transitions  T2, 
T3r  and  T4  are  enabled.  If  one  of  these  transitions  fires  then  a 
token  is  removed  from  SI  (thus  disenabling  the  two  nonfiring 
transitions)  and  placed  in  the  state  output  from  the  firing 
transition.  Thus  only  one  of  three  tasks  can  be  performed ;  its 
initialization  being  represented  by  the  firing  of  one  of  T2,  T3,  or 
T4. 


Representation  of  a  second  kind  of  synchronization  where  only 
one  of  a  number  of  tasks  need  be  completed  is  provided  for  by  the 
ability  of  a  state  to  have  multiple  input  transitions.  An  example 
of  this  is  given  in  figure  B-4.  If  one  of  T1,  T2,  or  T3  fires  then 
a  token  is  removed  from  the  transitions  input  state  and  placed  in 
S4  thus  enabling  T4.  This  type  of  configuration  might  be  used  in 
conjunction  with  figure  B-3  to  represent  making  a  decision  to 
perform  only  one  of  three  possible  tasks;  after  which  only  a 
routine  task  can  be  performed. 

One  potential  problem  with  this  last  configuration  is  that  more 


than  one 

of 

T1, 

T2,  or 

T3  could  fire. 

For  example  suppose  the 

firing  of 

T1, 

T2, 

and  T3 

represent  the 

termination  of  three 

concurrently  running  tasks  as  in  figure  B-1.  In  that  case  S4  could 
have  more  then  one  token  in  it.  If  T4  should  become  enabled  and 
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fire  only  one  token  will  be  removed  from  S4  leaving  any  where  from 
zero  to  two  tokens  in  it.  Thus  T4  could  remain  enabled  and 
immediately  fire  again.  This  type  of  enabling  and  firing  of  the 
same  transition  without  being  represented  graphically  in  the  Petri 
net  is  undesirable  because  of  the  confusion  and  errors  that  could 


arise . 
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CSRG-52  AUTOMATIC  GENERATION  OF  SYNTAX-REPAIRING  AND 
PARAGRAPHING  PARSERS 
David  T.  Barnard,  March  1975 
[M.Sc.  Thesis,  DCS,  1975] 

*  CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 

DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.),  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/l  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 

*  CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

*  CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 

Eric  C.R.  Hehner,  July  1975 

see  Acta  Informatica  Col.  10,  No. 3,  pp. 229-243,  1978 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference,  1975] 

*  CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 

OF  ABSTRACT  DATA  TYPES 
John  V.  Guttag,  September  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-60  NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 

RELATIONAL  DATA  BASE  MODEL 
Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS.  1975] 

*  CSRG-61  LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Conference,  1976] 
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*  CSRG-62  COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING  LANGUAGE 

SEMANTICS 

James  E.  Donahue,  November  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-63  AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis.  DCS,  1975] 

CSRG-64  A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster,  E.A.  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 
Conference  1976,  v.45,  pp. 855-862] 

CSRG-65  PERFORMANCE  EVALUATION  OF  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1,  n:4,  December  1976] 

CSRG-66  EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  R.  Cordy,  March  1978 
[M.Sc.  Thesis,  DCS,  1976] 

*  CSRG-68  A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco, 

April  1976 

CSRG-69  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  and  D.  Thompson  (eds.),  Fourth  Edition, 

May  1976 

*  CSRG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A.  Klug,  and  D.Tsichritzis,  May  1976 
[Proceedings  Very  Large  Data  Base  Conference,  1976] 

*  CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 

DATA  BASE  MACHINE 

E. A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

[ACM  Transactions  of  Database  Systems,  v.2,  n.4,  December  1977] 

*  CSRG-72  THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 

H.A.  Schmid  (ed.),  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S.  Pozgaj,  July  1976 
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CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A.  Bernstein  and  C.  Beeri,  September  1976 

*  CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

CSRG-76  SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 

[IEEE  Transactions  on  Software  Engineering,  v.SE-3,  n.4,  July  1977] 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham,  January  1977 

CSRG-73  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.),  February  1977 

CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  (ed.),  Fifth  Edition,  May  1977 

CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  GROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.),  First  Edition,  May  1977 

CSRG-82  NOTES  ON  EUCLID  "t 

edited  by  W.  David  Elliot  and  David  T.  Barnard,  August  1977  — - 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSRG-84  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowska,  September  1977 
[Ph.D.  Thesis,  DCS,  1977] 
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CSRG-86  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 
NETWORK  MODELS 
Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems,  Vienna,  1979] 

CSRG-87  ’OLGA1  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis,  E.S.  Lee, 

P.I.P.  Boulton,  November  1977 

CSRG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt,  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  Lawrence  Brodie,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton,  Guy  Fedorkow,  with  Ronald  Baecker, 

Gustav  Ciamaga,  Leslie  Mezei  andK.C.  Smith,  June  1978 

CSRG-93  A  DEVICE-INDEPENDENT, GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis,  CSRG,  October  1978] 
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CSRG-9B  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  I.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.),  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 

CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 

CSRG-106  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 

CSRG-107  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Cowey 
Steven  W.  Zucker,  DCS,  June  1979 

CSRG-108  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1980] 


